DHCPv6 Prefix Delegation in Long-Term Evolution (LTE) Networks
draft-sarikaya-v6ops-prefix-delegation-11

Network Working Group                                        B. Sarikaya
Internet-Draft                                                    F. Xia
Intended status: Informational                                Huawei USA
Expires: August 13, 2012                                        T. Lemon
                                                                 Nominum
                                                       February 10, 2012

    DHCPv6 Prefix Delegation  in Long Term Evolution  (LTE) Networks
             draft-sarikaya-v6ops-prefix-delegation-11.txt

Abstract

   As interest on IPv6 deployment is increasing in cellular networks
   several migration issues are being raised and IPv6 prefix management
   is the one addressed in this document.  Based on the idea that DHCPv6
   servers can manage prefixes, we address prefix management issues such
   as the access router offloading delegation and release tasks of the
   prefixes to a DHCPv6 server using DHCPv6 Prefix Delegation.  The
   access router first requests a prefix for an incoming mobile node
   from the DHCPv6 server.  The access router may next do stateless or
   stateful address allocation to the mobile node, e.g. with a Router
   Advertisement or using DHCP.  We also describe prefix management
   using Authentication Authorization and Accounting servers.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on August 13, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal

Sarikaya, et al.         Expires August 13, 2012                [Page 1]
Internet-Draft              Prefix Delegation              February 2012

   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology and Acronyms . . . . . . . . . . . . . . . . . . .  4
   3.  Prefix Delegation Using DHCPv6 . . . . . . . . . . . . . . . .  5
     3.1.  Prefix Request Procedure for Stateless Address
           Configuration  . . . . . . . . . . . . . . . . . . . . . .  5
     3.2.  Prefix Request Procedure for Stateful Address
           Configuration  . . . . . . . . . . . . . . . . . . . . . .  7
     3.3.  MN as Requesting Router in Prefix Delegation . . . . . . .  8
     3.4.  Prefix Release Procedure . . . . . . . . . . . . . . . . .  8
     3.5.  Miscellaneous Considerations . . . . . . . . . . . . . . .  9
       3.5.1.  How to Generate IAID . . . . . . . . . . . . . . . . .  9
       3.5.2.  Policy to Delegate Prefixes  . . . . . . . . . . . . . 10
   4.  Prefix Delegation Using RADIUS and Diameter  . . . . . . . . . 10
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   8.  Informative References . . . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13

Sarikaya, et al.         Expires August 13, 2012                [Page 2]
Internet-Draft              Prefix Delegation              February 2012

1.  Introduction

   Figure 1 illustrates the key elements of a typical cellular access
   network.  In a Long Term Evolution (LTE) network, access router is
   the packet data network (PDN) gateway [ThreeGPP23401].

                                       +-------------+
                                       |   +------+  |
                                       |   |DHCP  |  |
+-----+   +-----+   +------+  +------+ |   |Server|  | +------+
| MN  |---| BS  |---+Access+--+Access+-+   +------+  +-+Border|
+-----+   +-----+   |  GW  |  |Router| |IP Network(s)| |Router+-Internet
                    +--+---+  +--+---+ |             | +------+
                       |         |     +-------------+
+-----+   +-----+      |         |    +------+
| MN  |---| BS  |------+         |    |AAA   |
+-----+   +-----+                +--- |Server|
                                      +------+

           Figure 1: Key elements of a typical cellular network

   Mobile node (MN) attaches to a base station (BS) through LTE air
   interface.  A BS manages connectivity of UEs and extends connections
   to an Access Gateway (GW), e.g. the serving gateway (S-GW) in an LTE
   network.  The access gateway and the Access Router (AR) are connected
   with an IP network.  The access router is the first hop router of MNs
   and it is in charge of address/prefix management.

   Access router is connected to an IP network which is owned by the
   operator which is connected to the public Internet via a Border
   Router.  The network contains servers for subscriber management
   including Quality of Service, billing and accounting as well as
   Dynamic Host Configuration Protocol (DHCP) server [RFC6342].

   As to IPv6 addressing, because mobile network links are point-to-
   point (p2p) Per-MN interface prefix model is used [RFC3314],
   [RFC3316].  In Per-MN interface prefix model, prefix management is an
   issue.

   When an MN attaches an AR, the AR requests one or more prefixes for
   the MN.  When the MN detaches the AR, the prefixes should be
   released.  When the MN becomes idle, the AR should hold the prefixes
   allocated.

   This document describes how to use DHCPv6 Prefix Delegation (PD) in
   mobile networks such as networks based on standards developed by the
   3rd Generation Partnership Project (3GPP) and it could easily be
   adopted to Worldwide Interoperability for Microwave Access (WiMAX)

Sarikaya, et al.         Expires August 13, 2012                [Page 3]
Internet-Draft              Prefix Delegation              February 2012

   Forum as well.  In view of migration to IPv6, the number of mobile
   nodes connected to the network at a given time may become very high.
   Traditional techniques such as prefix pools are not scalable.  In
   such cases DHCPv6 PD becomes the viable approach to take.

   The techniques described in this document have not been approved
   either by the IETF or by 3GPP, except what is described below in
   Section 3.3.  This document is not a standard or best current
   practice.  This document is published only as a possibility for
   consideration by operators.

   This document is useful when address space needs to be managed by
   DHCPv6-PD.  There are obviously other means of managing address
   space, including having the AR track internally what address space is
   used by what mobile.

2.  Terminology and Acronyms

   3GPP 3rd Generation Partnership Project

   AAA Authentication Authorization and Accounting

   AR Access Router

   BS Base Station

   DHCP Dynamic Host Control Protocol

   E-UTRAN Evolved Universal Terrestrial Radio Access Network

   GPRS General Packet Radio Service

   LTE Long Term Evolution

   MN Mobile node

   PDN Packet data network

   PD Prefix Delegation

   p2p Point-to-point

   Serving Gateway S-GW

   WiMAX Worldwide Interoperability for Microwave Access

Sarikaya, et al.         Expires August 13, 2012                [Page 4]
Internet-Draft              Prefix Delegation              February 2012

3.  Prefix Delegation Using DHCPv6

   Access router refers to the cellular network entity that has DHCP
   Client.  According to [ThreeGPP23401] DHCP Client is located in PDN
   Gateway.  So AR is the PDN Gateway in LTE architecture.

3.1.  Prefix Request Procedure for Stateless Address Configuration

   There are two function modules in the AR, DHCP Client and DHCP Relay.
   DHCP messages should be relayed if the AR and a DHCP server are not
   connected directly, otherwise DHCP relay function in the AR is not
   necessary.  Figure 2 illustrates the scenario that the AR and the
   DHCP Server aren't connected directly:

       +-------+               +----------------------+    +-----------+
       |  MN   |               |       AR             |    |DHCP Server|
       +-------+               |DHCP     |  Relay     |    +-----------+
           |                   |Client   |  Agent     |          |
           |                   +----------------------+          |
           |1 Initial NW Entry |                                 |
           |or attach procedure|                                 |
           |<----------------->|                                 |
           |                   |2 Solicit                        |
           |                   |--------->         Relay-forward |
           |                   |                 --------------->|
           |                   |                   3 Relay-reply |
           |                   |Advertise        <---------------|
           |                   |<--------                        |
           |                   |4 Request                        |
           |                   |--------->         Relay-forward |
           |                   |                 --------------->|
           |                   |                   5 Relay-reply |
           |                   |Repl             <---------------|
           |                   |<--------                        |
           |6  Attach          |                                 |
           | Completed         |                                 |
           |<----------------->|                                 |
           |7 Router           |                                 |
           |  Solicitation     |                                 |
           |------------------>|                                 |
           | 8 Router          |                                 |
           |  Advertisement    |                                 |
           |<------------------|                                 |

                         Figure 2: Prefix request

Sarikaya, et al.         Expires August 13, 2012                [Page 5]
Internet-Draft              Prefix Delegation              February 2012

   1.  An MN (UE=User Equipment in 3GPP) performs initial network entry
       and authentication procedures, a.k.a. attach procedure.
   2.  On successful completion of Step 1, the AR initiates DHCP Solicit
       procedure to request prefixes for the MN.  The DHCP Client in AR
       creates and transmits a Solicit message as described in sections
       17.1.1, "Creation of Solicit Messages" and 17.1.2, "Transmission
       of Solicit Messages" of [RFC3315].  The DHCP Client in AR that
       supports DHCPv6 Prefix Delegation [RFC3633] creates an Identity
       Association for Prefix Delegation (IA_PD) and assigns it an
       Identity Association IDentifier (IAID).  The client must include
       the IA_PD option in the Solicit message.  DHCP Client as
       Requesting Router must set prefix-length field to a value less
       than, e.g. 48 or equal to 64 to request a /64 prefix.  Next, the
       Relay Agent in AR sends Relay-Forward message to the DHCP Server
       encapsulating Solicit message.
   3.  The DHCP server sends an Advertise message to the AR in the same
       way as described in section 17.2.2, "Creation and transmission of
       Advertise messages" of [RFC3315].  Advertise message with IA_PD
       shows that the DHCP server is capable of delegating prefixes.
       This message is received encapsulated in Relay-Reply message by
       the Relay Agent in AR and sent as Advertise message to the DHCP
       Client in AR.
   4.  The AR (DHCP Client and Relay Agent) uses the same message
       exchanges as described in section 18, "DHCP Client-Initiated
       Configuration Exchange" of [RFC3315] and [RFC3633] to obtain or
       update prefixes from the DHCP server.  The AR (DHCP Client and
       Relay Agent) and the DHCP server use the IA_PD Prefix option to
       exchange information about prefixes in much the same way as IA
       Address options are used for assigned addresses.  This is
       accomplished by the AR sending a DHCP Request message and the
       DHCP server sending a DHCP Reply message.
   5.  AR stores the prefix information it received in the Reply
       message.
   6.  A connection between MN and AR is established and the link
       becomes active.  This step completes the PDP Context Activation
       Procedure in UMTS and PDN connection establishment in LTE
       networks.
   7.  The MN may send a Router Solicitation message to solicit the AR
       to send a Router Advertisement message.
   8.  The AR advertises the prefixes received in IA_PD option to MN
       with router advertisement (RA) once the PDP Context/PDN
       connection is established or in response to Router Solicitation
       message sent from the MN.

   4-way exchange between AR as requesting router (RR) and DHCP server
   as delegating router (DR) in Figure 2 may be reduced into a two
   message exchange using the Rapid Commit option [RFC3315].  DHCP
   Client in AR acting as RR includes a Rapid Commit option in the

Sarikaya, et al.         Expires August 13, 2012                [Page 6]
Internet-Draft              Prefix Delegation              February 2012

   Solicit message.  DR then sends a Reply message containing one or
   more prefixes.

3.2.  Prefix Request Procedure for Stateful Address Configuration

   Stateful address configuration requires a different architecture than
   shown in Figure 2.  There are two function modules in the AR, DHCP
   Server and DHCP Client.

   After the initial attach is completed, a connection to the AR is
   established for the MN.  DHCP Client function at the AR as requesting
   router and DHCP server as delegating router follow Steps 2 through 5
   of the procedure shown in Figure 2 to get the new prefix for this
   interface of MN from IA_PD Option exchange defined in [RFC3633].

   DHCPv6 client at the MN sends DHCP Request to AR.  DHCP Server
   function at the AR must use the IA_PD option received in DHCP PD
   exchange to assign an address to MN.  IA_PD option must contain the
   prefix.  AR sends DHCP Reply message to MN containing IA address
   option (IAADDR).  Figure 3 shows the message sequence.

   MN configures its interface with the address assigned by DHCP server
   in DHCP Reply message.

   In Figure 3 AR may be the home gateway of a fixed network to which MN
   gets connected during MN's handover.

Sarikaya, et al.         Expires August 13, 2012                [Page 7]
Internet-Draft              Prefix Delegation              February 2012

     +----------+             +--------------+             +-----------+
     |  MN      |             |    AR        |             |DHCP Server|
     |   |DHCP  |             | DHCP |DHCP   |             +-----------+
     |   |Client|             |Server|Client |
     +----------+             +--------------+
         |  Initial NW Entry     |                           |
         |or attach procedure    |                           |
         |<----------------->    |                           |
         |                       |      DHCP PD exchange     |
         |                       |      similar to Steps 2-5 |
         |   Solicit             |      of Figure 2 (IA_PD)  |
         |---------------------->|                           |
         |   Advertise           |                           |
         |<----------------------|                           |
         |    Request            |                           |
         |---------------------->|                           |
         |                       |                           |
         |                       |                           |
         |                       | use prefix in IA_PD       |
         |    Reply              | to assign IAADDR          |
         |<--------------------- |                           |

           Figure 3: Stateful Address Configuration Following PD

3.3.  MN as Requesting Router in Prefix Delegation

   AR may use DHCPv6 prefix delegation exchange to get a delegated
   prefix shorter than /64 by setting prefix-length field to a value
   less than 64, e.g. 56 to get a /56 prefix.  Each newly attaching MN
   first goes through the steps in Figure 2 in which AR requests a
   shorter prefix to establish a default connection with the MN.

   MN may next request additional prefixes (/64 or shorter) from the AR
   using DHCPv6 prefix delegation where MN is the requesting router and
   AR is the delegating router [RFC6459], Section 5.3.1.2.6 in
   [ThreeGPP23401].  In this case the call flow is similar to Figure 3.
   Solicit message must include the IA_PD option with prefix-length
   field set to 64.  MN may request more than one /64 prefixes.  AR as
   delegating router must delegate these prefixes excluding the prefix
   assigned to the default connection.

3.4.  Prefix Release Procedure

   Prefixes can be released in two ways, prefix aging or DHCP release
   procedure.  In the former way, a prefix should not be used by an MN
   when the prefix ages, and the DHCP Server can delegate it to another
   MN.  A prefix lifetime is delivered from the DHCPv6 server to the MN

Sarikaya, et al.         Expires August 13, 2012                [Page 8]
Internet-Draft              Prefix Delegation              February 2012

   through DHCP IA_PD Prefix option [RFC3633] and RA Prefix Information
   option [RFC4861].  Figure 4 illustrates how the AR releases prefixes
   to a DHCP Server which isn't connected directly:

   1.  An MN detachment signaling, such as switch-off or handover,
       triggers prefix release procedure.
   2.  The AR initiates a Release message to give back the prefixes to
       the DHCP server.
   3.  The server responds with a Reply message, and then the prefixes
       can be reused by other MNs.

       +-------+               +-------+             +-----------+
       |  MN   |               |  AR   |             |DHCP Server|
       +-------+               +-------+             +-----------+
           |                       |                       |
           |  1 De-registration    |                       |
           |  Handover, or others  |                       |
           |<--------------------->|                       |
           |                       |2 Relay-forward/Release|
           |                       |---------------------->|
           |                       |                       |
           |                       |3 Relay-reply/Reply    |
           |                       |<--------------------- |
           |                       |                       |
           |                       |                       |

                         Figure 4: Prefix Release

3.5.  Miscellaneous Considerations

3.5.1.  How to Generate IAID

   IAID is 4 bytes in length and should be unique in an AR scope.
   Prefix table should be maintained.  Prefix table contains IAID, MAC
   address and the prefix(es) assigned to MN.  In LTE networks,
   International Mobile station Equipment Identity (IMEI) uniquely
   identifies MN's interface and thus corresponds to the MAC address.
   MAC address of the interface should be stored in the prefix table and
   this field is used as the key for searching the table.

   IAID should be set to Start_IAID, an integer of 4 octets.  The
   following IAID generation algorithm is used:

   1.  Set this IAID value in IA_PD Prefix Option.  Request prefix for
       this MN as in Section 3.1 or Section 3.2.
   2.  Store IAID, MAC address and the prefix(es) received in the next
       entry of the prefix table.

Sarikaya, et al.         Expires August 13, 2012                [Page 9]
Internet-Draft              Prefix Delegation              February 2012

   3.  Increment IAID.

   Prefix table entry for an MN that hands over to another AR must be
   removed.  IAID value is released to be reused.

3.5.2.  Policy to Delegate Prefixes

   In point-to-point links, if /64 prefixes of all the MNs connected to
   one or more ARs are broadcast dynamically upstream as the route
   information this causes high routing protocol traffic (IGP, OSPF,
   etc.) due to Per-MN interface prefixes.  There are two solutions this
   problem.  One is to use static configuration, which would be
   preferable in many cases.  No routing protocols are needed, because
   each AR has a known piece of address space.  If the DHCP servers know
   this space, too, then they will assign from that space to a
   particular AR.

   The other method is to use route aggregation.  For example, each AR
   can be assigned a /48 or /32 prefix (aggregate prefix, aka service
   provider common prefix) while each interface of MN can be assigned a
   /64 prefix.  The /64 prefix is an extension of /48 one, for example,
   an AR's /48 prefix is 2001:DB8:0::/48, an interface of MN is assigned
   2001:DB8:0:2::/64 prefix.  The border router (BR) in Figure 1 may be
   manually configured to broadcast only individual AR's /48 or /32
   prefix information to Internet.

4.  Prefix Delegation Using RADIUS and Diameter

   In the initial network entry procedure Figure 2, AR as Remote
   Authentication Dial In User Service (RADIUS) client sends Access-
   Request message with MN information to RADIUS server.  If the MN
   passes the authentication, the RADIUS server may send Access-Accept
   message with prefix information to the AR using Framed-IPv6-Prefix
   attribute.  AAA server also provides routing information to be
   configured for MN on the AR using Framed-IPv6-Route attribute.  Using
   such a process AR can handle initial prefix assignments to MNs but
   managing lifetime of the prefixes is totally left to the AR.  Framed-
   IPv6-Prefix is not designed to support delegation of IPv6 prefixes.
   For this Delegated-IPv6-Prefix attribute can be used which is
   discussed next.

   [RFC4818] defines a RADIUS attribute Delegated-IPv6-Prefix that
   carries an IPv6 prefix to be delegated.  This attribute is usable
   within either RADIUS or Diameter.  [RFC4818] recommends the
   delegating router to use AAA server to receive the prefixes to be
   delegated using Delegated-IPv6-Prefix attribute/AVP.

Sarikaya, et al.         Expires August 13, 2012               [Page 10]
Internet-Draft              Prefix Delegation              February 2012

   DHCP server as the delegating router in Figure 2 may send an Access-
   Request packet containing Delegated-IPv6-Prefix attribute to the
   RADIUS server to request prefixes.  In the Access-Request message,
   the delegating router may provide a hint that it would prefer a
   prefix, for example, a /48 prefix.  As the RADIUS server is not
   required to honor the hint, the server may delegate longer prefix,
   e.g. /56 or /64 in an Access-Accept message containing Delegated-
   IPv6-Prefix attribute [RFC4818].  The attribute can appear multiple
   times when RADIUS server delegates multiple prefixes to the
   delegating router.  The delegating router sends the prefixes to the
   requesting router using IA_PD Option and AR as RR uses them for MN's
   as described in Section 3.

   When Diameter is used, DHCP server as the delegating router in
   Figure 2 sends AA-Request message.  AA-Request message may contain
   Delegated-IPv6-Prefix AVP.  Diameter server replies with AA-Answer
   message.  AA-Answer message may contain Delegated-IPv6-Prefix AVP.
   The AVP can appear multiple times when Diameter server assigns
   multiple prefixes to MN.  The Delegated-IPv6-Prefix AVP may appear in
   an AA-Request packet as a hint by the AR to the Diameter server that
   it would prefer a prefix, for example, a /48 prefix.  Diameter server
   may delegate in an AA-Answer message with a /64 prefix which is an
   extension of the /48 prefix.  As in the case of RADIUS, the
   delegating router sends the prefixes to the requesting router using
   IA_PD Option and AR as RR uses them for MN's as described in
   Section 3.

5.  Security Considerations

   This draft introduces no additional messages.  Comparing to
   [RFC3633], [RFC2865] and [RFC3588] there is no additional threats to
   be introduced.  DHCPv6, RADIUS and Diameter security procedures
   apply.

6.  IANA Considerations

   None.

7.  Acknowledgements

   We are grateful to Suresh Krishnan, Hemant Singh, Qiang Zhao, Ole
   Troan, Qin Wu, Jouni Korhonen, Cameron Byrne, Brian Carpenter, Jari
   Arkko and Jason Lin who provided in depth reviews of this document
   that have led to several improvements.

Sarikaya, et al.         Expires August 13, 2012               [Page 11]
Internet-Draft              Prefix Delegation              February 2012

8.  Informative References

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

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, June 2000.

   [RFC3314]  Wasserman, M., "Recommendations for IPv6 in Third
              Generation Partnership Project (3GPP) Standards",
              RFC 3314, September 2002.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC3316]  Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J.
              Wiljakka, "Internet Protocol Version 6 (IPv6) for Some
              Second and Third Generation Cellular Hosts", RFC 3316,
              April 2003.

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              December 2003.

   [RFC4818]  Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix
              Attribute", RFC 4818, April 2007.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

   [RFC6342]  Koodli, R., "Mobile Networks Considerations for IPv6
              Deployment", RFC 6342, August 2011.

   [RFC6459]  Korhonen, J., Soininen, J., Patil, B., Savolainen, T.,
              Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation
              Partnership Project (3GPP) Evolved Packet System (EPS)",
              RFC 6459, January 2012.

   [ThreeGPP23401]
              "3GPP TS 23.401 V11.0.0, General Packet Radio Service
              (GPRS) enhancements for Evolved Universal Terrestrial
              Radio Access Network  (E-UTRAN) access (Release 11).",

Sarikaya, et al.         Expires August 13, 2012               [Page 12]
Internet-Draft              Prefix Delegation              February 2012

              2011.

Authors' Addresses

   Behcet Sarikaya
   Huawei USA
   5340 Legacy Dr.
   Plano, TX  75074

   Email: sarikaya@ieee.org

   Frank Xia
   Huawei USA
   1700 Alma Dr. Suite 500
   Plano, TX  75075

   Phone: +1 972-509-5599
   Email: xiayangsong@huawei.com

   Ted Lemon
   Nominum
   2000 Seaport Blvd
   Redwood City, CA  94063

   Phone:
   Email: mellon@nominum.com

Sarikaya, et al.         Expires August 13, 2012               [Page 13]