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

Versions: 00 01 02 03 04 05 06 RFC 6611

Network Working Group                               K. Chowdhury, Editor
Internet-Draft                                          Starent Networks
Intended status: Standards Track                                A. Yegin
Expires: August 11, 2007                                     Samsung AIT
                                                        February 7, 2007


             MIP6-bootstrapping for the Integrated Scenario
            draft-ietf-mip6-bootstrapping-integrated-02.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 will expire on August 11, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).













Chowdhury, Editor & Yegin  Expires August 11, 2007              [Page 1]

Internet-Draft                                             February 2007


Abstract

   The Mobile IPv6 bootstrapping problem statement describes two main
   scenarios.  In the first scenario (i.e. the split scenario), the
   mobile node's mobility service is authorized by a different service
   authorizer than the basic network access authorizer.  In the second
   scenario (i.e. the integrated scenario), the mobile node's mobility
   service is authorized by the same service authorizer as the basic
   network access service authorizer.  This document defines a method
   for home agent information discovery for the integrated scenario.


Table of Contents

   1.  Introduction and Scope . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Solution Overview  . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Logical Diagram of the Integrated Scenario . . . . . . . .  5
     3.2.  Bootstrapping Message Sequence, Success Case . . . . . . .  6
       3.2.1.  Home Agent allocation in the MSP . . . . . . . . . . .  6
       3.2.2.  Home Agent allocation in the ASP . . . . . . . . . . .  8
     3.3.  Bootstrapping Message Sequence: Fallback case  . . . . . . 10
     3.4.  HoA and IKEv2 SA Bootstrapping in the Integrated
           Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 10
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   7.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
   Intellectual Property and Copyright Statements . . . . . . . . . . 19


















Chowdhury, Editor & Yegin  Expires August 11, 2007              [Page 2]

Internet-Draft                                             February 2007


1.  Introduction and Scope

   The Mobile IPv6 protocol [RFC3775] requires the mobile node to have
   knowledge of its Home Address, the home agent address and the
   cryptographic materials for establishing an IPsec security
   association with the home agent prior to performing home
   registration.  The mechanism via which the mobile node obtains these
   information is called Mobile IPv6 bootstrapping.  In order to allow a
   flexible deployment model for Mobile IPv6, it is desirable to define
   a bootstrapping mechanism for the mobile node to acquire these
   parameters dynamically.  The [RFC4640] describes the problem
   statement for Mobile IPv6 bootstrapping.  It also defines two
   bootstrapping scenarios based on the relationship between the entity
   that authenticates and authorizes the mobile node for network access
   (i.e., the Access Service Authorizer) and the entity that
   authenticates and authorizes the mobile node for mobility service
   (i.e., the Mobility Service Authorizer).  The scenario in which the
   Access Service Authorizer is not the Mobility Service Authorizer is
   called the "Split" scenario.  The bootstrapping solution for split
   scenario is defined in [BOOT-SPLIT].  The scenario in which the
   Access Service Authorizer is also the Mobility Service Authorizer is
   called the "Integrated" scenario.  This document defines a
   bootstrapping solution for the Integrated scenario.

   [BOOT-SPLIT] identifies four different components of the
   bootstrapping problem: home agent address discovery, HoA assignment,
   IPsec Security Association setup and Authentication and Authorization
   with the MSA.  This document defines a mechanism for home agent
   address discovery.  For the rest of components, please refer to
   [BOOT-SPLIT].

   In the integrated scenario, the bootstrapping of the home agent
   information can be performed via DHCPv6.  DHCPv6 is designed for
   configuration management and it is being deployed by operators to
   handle their configuration management needs in their networks.
















Chowdhury, Editor & Yegin  Expires August 11, 2007              [Page 3]

Internet-Draft                                             February 2007


2.  Terminology

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   General mobility terminology can be found in [RFC3753].  The
   following additional terms, as defined in [RFC4640], are used in this
   document:

   Access Service Authorizer (ASA): A network operator that
   authenticates a mobile node and establishes the mobile node's
   authorization to receive Internet service.

   Access Service Provider (ASP): A network operator that provides
   direct IP packet forwarding to and from the mobile node.

   Mobility Service Authorizer (MSA): A service provider that authorizes
   Mobile IPv6 service.

   Mobility Service Provider (MSP): A service provider that provides
   Mobile IPv6 service.  In order to obtain such service, the mobile
   node must be authenticated and authorized to obtain the Mobile IPv6
   service.

   Split scenario: A scenario where the mobility service and the network
   access service are authorized by different entities.

   Integrated Scenario: A scenario where the mobility service and the
   network access service are authorized by the same entity.





















Chowdhury, Editor & Yegin  Expires August 11, 2007              [Page 4]

Internet-Draft                                             February 2007


3.  Solution Overview

3.1.  Logical Diagram of the Integrated Scenario

   In the integrated scenario the mobile node utilizes network access
   authentication process to bootstrap Mobile IPv6.  It is assumed that
   the access service authorizer is mobility service aware.  This allows
   for Mobile IPv6 bootstrapping at the time of access authentication
   and authorization.  Also, the mechanism defined in this document
   requires the NAS to support Mobile IPv6 specific AAA attributes and a
   collocated DHCP relay agent.

   The following diagram shows the network elements and layout in the
   integrated scenario:


                                      |
                  ASP(/MSP)           |   ASA/MSA(/MSP)
                                      |
                                      |
                  +-------+           |        +-------+
                  |       |           |        |       |
                  |AAAV   |-----------|--------|AAAH   |
                  |       |           |        |       |
                  |       |           |        |       |
                  +-------+           |        +-------+
                      |               |
                      |               |
                      |               |
                      |               |
                      |               |
                      |               |
                      |               |
                  +-----+    +------+ |
      +----+      |     |    |DHCP  | |
      | MN |------| NAS/|----|Server| |
      +----+      |Relay|    |      | |
                  +-----+    +------+ |
                                      |
                                      |
                  +--------+          |      +--------+
                  | HA     |          |      | HA     |
                  | in ASP |          |      |in MSP  |
                  +--------+          |      +--------+







Chowdhury, Editor & Yegin  Expires August 11, 2007              [Page 5]

Internet-Draft                                             February 2007


              Integrated Scenario, Network Diagram with DHCP

   Figure 1.  Integrated Scenario, Network Diagram with DHCP

   Figure 1 shows the AAA infrastructure with a AAA client (NAS), a AAA
   proxy in the visited network and a AAA server in the home network.
   The user's home network authorizes the mobile node for network access
   and also for mobility services.  Note that a home agent for usage
   with the mobile node might be selected in the access service
   provider's network or alternatively in the mobility service
   provider's network.

   The mobile node interacts with the DHCP Server via the Relay Agent
   after the network access authentication as part of the mobile node
   configuration procedure.

3.2.  Bootstrapping Message Sequence, Success Case

   In the success case, the mobile node is able to acquire the home
   agent address via a DHCPv6 query.  The message flows for home agent
   allocation in the ASP and the MSP are illustrated below.  Since, in
   the integrated scenario, the ASA and the MSA are the same, it can be
   safely assumed that the AAAH used for network access authentication
   (ASA) has access to the same database as the AAAH used for the
   mobility service authentication (MSA).  Hence, the same AAAH can
   authorize the mobile node for network access and mobility service at
   the same time.

3.2.1.  Home Agent allocation in the MSP

   This section describes a scenario where the home agent is allocated
   in the mobile node's home MSP network. in order to provide the mobile
   node with information about the assigned home agent the AAAH conveys
   the assigned home agent's information to the NAS via AAA protocol
   [MIP6-RADIUS] or [MIP6-Dime].
















Chowdhury, Editor & Yegin  Expires August 11, 2007              [Page 6]

Internet-Draft                                             February 2007


                                         |
                 --------------ASP------>|<--ASA+MSA--
                                         |
   +----+        +------+      +-------+   +-----+
   |    |        |      |      |       |   |     |
   | MN/|            |NAS/  |      | DHCP  |   |AAAH |
   |User|            |DHCP  |      | Server|   |     |
   |    |        |relay |      | Server|   |     |
   +----+        +------+      +-------+   +-----+
     |               |             |          |
     |     1         |          1  |          |
     |<------------->|<---------------------->|
     |               |             |          |
     |               |             |          |
     |     2         |             |          |
     |-------------->|             |          |
     |               |             |          |
     |               |       3     |          |
     |               |------------>|          |
     |               |             |          |
     |               |       4     |          |
     |               |<------------|          |
     |               |             |          |
     |     5         |             |          |
     |<--------------|             |          |
     |               |             |          |


                           Home Agent in the MSP

   Figure 2.  The home agent allocation in the home MSP

   Figure 2 shows the message sequence for home agent allocation in the
   home MSP.

   (1) The mobile node executes the network access authentication
   procedure (e.g., IEEE 802.11i/802.1X) and thereby interacts with the
   NAS.  The NAS is in the ASP and it interacts with the AAAH, which is
   in the ASA/MSA, to authenticate the mobile node.  In the process of
   authorizing the mobile node the AAAH verifies in the AAA profile that
   the mobile node is allowed to use Mobile IPv6 service.  The AAAH
   assigns a home agent in the home MSP and returns this information to
   the NAS.

   (2) The mobile node sends a DHCPv6 Information Request message
   [RFC3315] to the All_DHCP_Relay_Agents_and_Servers multicast address.
   In this message the mobile node (DHCP client) SHALL include the
   Option Code for Home Network Identifier Option [HIOPT] in the



Chowdhury, Editor & Yegin  Expires August 11, 2007              [Page 7]

Internet-Draft                                             February 2007


   OPTION_ORO, Home Network Identifier Option with id-type set to 1 and
   the Home Network Identifier field set to the network realm of the
   home MSP [HIOPT].  The mobile node SHALL also include the
   OPTION_CLIENTID to identify itself to the DHCP server.

   (3) The Relay Agent intercepts the Information Request from the
   mobile node and forwards it to the DHCP server.  The Relay Agent also
   includes the received home agent information from the AAAH in the
   OPTION_MIP6-RELAY-Option [HIOPT].

   (4) The DHCP server identifies the client by looking at the DUID for
   the client in the OPTION_CLIENTID.  The DHCP server also determines
   that the mobile node is requesting home agent information in the MSP
   by looking at the Home Network Identifier Option (id-type 1).  The
   DHCP server determines that the home agent is allocated by the AAAH
   by looking at the MIP6 home agent sub-option in the OPTION_MIP6-
   RELAY-Option.  The DHCP server extracts the allocated home agent
   information from the OPTION_MIP6-RELAY-Option and includes it in the
   Home Network Information Option [HIOPT] in the Reply Message.

   (5) The Relay Agent relays the Reply Message from the DHCP server to
   the mobile node.  At this point, the mobile node has the home agent
   information that it requested.

3.2.2.  Home Agent allocation in the ASP

   This section describes a scenario where the mobile node requests for
   home agent allocation in the ASP by setting the id-type field to zero
   in the Home Network Identifier Option in the DHCPv6 request message.
   In this scenario, the ASP becomes the MSP for the duration of the
   network access authentication session.




















Chowdhury, Editor & Yegin  Expires August 11, 2007              [Page 8]

Internet-Draft                                             February 2007


                                           |
                 --------------ASP-------->|<--ASA+MSA--
                                           |
   +----+        +-------+      +-------+    +------+
   |    |        |       |      |       |    |      |
   | MN/|            | NAS/  |      | DHCP  |    |AAAH  |
   |User|            | DHCP  |      | Server|    |      |
   |    |        | relay |      | Server|    |      |
   +----+        +-------+      +-------+    +------+
     |               |              |           |
     |     1         |          1   |           |
     |<------------->|<------------------------>|
     |               |              |           |
     |               |              |           |
     |     2         |              |           |
     |-------------->|              |           |
     |               |              |           |
     |               |       3      |           |
     |               |------------->|           |
     |               |              |           |
     |               |       4      |           |
     |               |<-------------|           |
     |               |              |           |
     |     5         |              |           |
     |<--------------|              |           |
     |               |              |           |


                           Home Agent in the ASP

   Figure 3.  The home agent allocation in the ASP

   Figure 3 shows the message sequence for home agent allocation in the
   ASP.

   (1) The mobile node executes the network access authentication
   procedure (e.g., IEEE 802.11i/802.1X) and thereby interacts with the
   NAS.  The NAS is in the ASP and it interacts with the AAAH, which is
   in the ASA/MSA, to authenticate the mobile node.  In the process of
   authorizing the mobile node the AAAH verifies in the AAA profile that
   the mobile node is allowed to use Mobile IPv6 services.  The AAAH
   assigns a home agent in the home MSP and returns this information to
   the NAS.  Note that the AAAH is not aware of the fact that the mobile
   node will rather request for a home agent allocation in the ASP.
   Therefore the assigned home agent may not be used by the mobile node.
   This leaves the location of the mobility anchor point decision to the
   mobile node.




Chowdhury, Editor & Yegin  Expires August 11, 2007              [Page 9]

Internet-Draft                                             February 2007


   (2) The mobile node sends a DHCPv6 Information Request message
   [RFC3315] to the All_DHCP_Relay_Agents_and_Servers multicast address.
   In this message the mobile node (DHCP client) SHALL include the
   Option Code for Home Network Identifier Option [HIOPT] in the
   OPTION_ORO, Home Network Identifier Option with id-type set to 0.
   The mobile node SHALL also include the OPTION_CLIENTID to identify
   itself to the DHCP server.

   (3) The Relay Agent intercepts the Information Request from the
   mobile node and forwards it to the DHCP server.  The Relay Agent
   (which is the NAS) also includes the received AAA AVP from the AAAH
   in the OPTION_MIP6-RELAY-Option [HIOPT].

   (4) The DHCP server identifies the client by looking at the DUID for
   the client in the OPTION_CLIENTID.  The DHCP server also determines
   that the mobile node is requesting home agent information in the ASP
   by looking at the Home Network Identifier Option (id-type 0).  If
   configured to do so, the DHCP server allocates an home agent from its
   configured list of home agents and includes it in the Home Network
   Information Option [HIOPT] in the Reply Message.  Note that in this
   case, the DHCP server does not use the received information in the
   OPTION_MIP6-RELAY-Option.

   (5) The Relay Agent relays the Reply Message from the DHCP server to
   the mobile node.  At this point, the mobile node has the home agent
   information that it requested.

3.3.  Bootstrapping Message Sequence: Fallback case

   In the fallback case, the mobile node is not able to acquire the home
   agent information via DHCPv6.  The mobile node MAY perform DNS
   queries to discover the home agent address as defined in
   [BOOT-SPLIT].  To perform DNS based home agent discovery, the mobile
   node needs to know the DNS server address.  How the mobile node knows
   the DNS server address is outside the scope of this document.

3.4.  HoA and IKEv2 SA Bootstrapping in the Integrated Scenario

   In the integrated scenario, the HoA, IPsec Security Associations
   setup, and Authentication and Authorization with the MSA are
   bootstrapped via the same mechanism as described in the bootstrapping
   solution for split scenario [BOOT-SPLIT].









Chowdhury, Editor & Yegin  Expires August 11, 2007             [Page 10]

Internet-Draft                                             February 2007


4.  Security Considerations

   The transport of the assigned home agent information via the AAA
   infrastructure (i.e., from the AAA server to the AAA client) to the
   NAS is subject to the standard RADIUS and Diameter security
   considerations.  No new security considerations are imposed by the
   usage of this document.  The security mechanisms provided by
   [RFC2865] and [RFC3588] are applicable and provide adequate security
   for this purpose.

   The communication between the NAS/DHCP relay agent to the DHCP server
   must be authenticated, integrity and replay protected.  Deployments
   MAY either rely on lower-layer security, (i.e., physical or link
   layer security), or rely on security mechanisms specifically defined
   for DHCPv6, such as [RFC4030].

   The communication between the DHCP client and the DHCP server for the
   exchange of home agent information is security sensitive and requires
   authentication, integrity and replay protection.  Either lower-layer
   security (such as link layer security established as part of the
   network access authentication protocol run) or DHCP security
   [RFC3118] can be used.  The latter approach is only applicable in
   non-roaming environments due to the limited applicability of the DHCP
   security mechanisms.  An adversary that is able to modify home agent
   information can force the mobile node to use a different home agent
   than intended by the MSA.  However, this type of attack can be
   detected by the security mechanism between the mobile node and the
   home agent.

   Overall, the home agent information carried by the AAA protocols and
   DHCP does not impose any new security concerns for the transport
   protocols.

   If the home agent selected by the mobile node is local or nearby, (as
   in section 3.2.2), disclosing the mobile node's home address (e.g.,
   by updating the mobile node's FQDN in the DNS) has the potential to
   expose some information about the mobile node's location.

   Just by knowing the mobile node's home address, an attacker cannot
   determine whether the mobile node's home address belongs to a home
   agent that is local, nearby or remote for the mobile node and, hence,
   cannot determine where the mobile node is actually located.  However,
   if additional information such as the mobile node's home agent
   selection policy and the home agent allocation policy of ASPs is
   known by an attacker, this may be different.  For instance, if an
   attacker knows that the mobile node's home agent selection policy is
   to bootstrap with a new local home agent whenever entering a new
   network (e.g., because the mobile node wants to improve routing



Chowdhury, Editor & Yegin  Expires August 11, 2007             [Page 11]

Internet-Draft                                             February 2007


   efficiency in Bi-directional Tunneling mode), the attacker can track
   the mobile node's movement if it is aware of the mobile node's
   current home addresses.  The accuracy of the revealed location
   information depends on the deployment style of home agents and the
   frequency of bootstrapping.

   Consequently, if a high level of location privacy is desired, a
   mobile node should not switch to local home agents in an eager manner
   or should not reveal its home address to untrusted nodes.
   Furthermore, the disclosure of policy information that can help
   locating the mobile node should be carefully considered.








































Chowdhury, Editor & Yegin  Expires August 11, 2007             [Page 12]

Internet-Draft                                             February 2007


5.  IANA Considerations

   None
















































Chowdhury, Editor & Yegin  Expires August 11, 2007             [Page 13]

Internet-Draft                                             February 2007


6.  Acknowledgements

   The authors would like to thank Kilian Weniger for his valuable
   comment related to location privacy.















































Chowdhury, Editor & Yegin  Expires August 11, 2007             [Page 14]

Internet-Draft                                             February 2007


7.  Contributors

   This contribution is a joint effort of the bootstrapping solution
   design team of the MIP6 WG.  The contributors include Gerardo
   Giaretta, Basavaraj Patil, Alpesh Patel, Jari Arkko, James Kempf,
   Gopal Dommety, Alper Yegin, Junghoon Jee, Vijay Devarapalli, Kuntal
   Chowdhury, Julien Bournelle, and Hannes Tschofenig.

   The design team members can be reached at:

   Gerardo Giaretta gerardo.giaretta@tilab.com

   Basavaraj Patil basavaraj.patil@nokia.com

   Alpesh Patel alpesh@cisco.com

   Jari Arkko jari.arkko@kolumbus.fi

   James Kempf kempf@docomolabs-usa.com

   Gopal Dommety gdommety@cisco.com

   Alper Yegin alper.yegin@samsung.com

   Junghoon Jee jhjee@etri.re.kr

   Vijay Devarapalli vijayd@iprg.nokia.com

   Kuntal Chowdhury kchowdhury@starentnetworks.com

   Julien Bournelle julien.bournelle@int-evry.fr

   Hannes Tschofenig hannes.tschofenig@siemens.com


















Chowdhury, Editor & Yegin  Expires August 11, 2007             [Page 15]

Internet-Draft                                             February 2007


8.  References

8.1.  Normative References

   [HIOPT]    Hee Jang et. al., A., "DHCP Option for Home Agent
              Discovery in MIPv6.", draft-ietf-mip6-hiopt-01.txt (work
              in progress), December 2006.

   [MIP6-Dime]
              Korhonen et. al., J., "Diameter Mobile IPv6: NAS - HAAA
              Support.", draft-ietf-dime-mip6-integrated-02.txt (work in
              progress), January 2007.

   [MIP6-RADIUS]
              Chowdhury et. al., K., "RADIUS Mobile IPv6 Support.",
              draft-ietf-mip6-radius-01.txt (work in progress),
              October 2006.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

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

   [RFC3118]  Droms, R. and W. Arbaugh, "Authentication for DHCP
              Messages", RFC 3118, June 2001.

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

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

   [RFC3753]  Manner, J. and M. Kojo, "Mobility Related Terminology",
              RFC 3753, June 2004.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC4005]  Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
              "Diameter Network Access Server Application", RFC 4005,
              August 2005.




Chowdhury, Editor & Yegin  Expires August 11, 2007             [Page 16]

Internet-Draft                                             February 2007


   [RFC4030]  Stapp, M. and T. Lemon, "The Authentication Suboption for
              the Dynamic Host Configuration Protocol (DHCP) Relay Agent
              Option", RFC 4030, March 2005.

   [RFC4640]  Patel, A. and G. Giaretta, "Problem Statement for
              bootstrapping Mobile IPv6 (MIPv6)", RFC 4640,
              September 2006.

8.2.  Informative References

   [BOOT-SPLIT]
              Giaretta et. al., A., "Mobile IPv6 bootstrapping in split
              scenario.", draft-ietf-mip6-bootstrapping-split-04.txt
              (work in progress), December 2006.





































Chowdhury, Editor & Yegin  Expires August 11, 2007             [Page 17]

Internet-Draft                                             February 2007


Authors' Addresses

   Kuntal Chowdhury
   Starent Networks
   30 International Place
   Tewksbury, MA  01876
   US

   Phone: +1 214-550-1416
   Email: kchowdhury@starentnetworks.com


   Alper Yegin
   Samsung AIT
   Istanbul,
   Turkey

   Phone:
   Email: alper01.yegin@partner.samsung.com
































Chowdhury, Editor & Yegin  Expires August 11, 2007             [Page 18]

Internet-Draft                                             February 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.

   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, THE IETF TRUST 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.


Intellectual Property

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


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Chowdhury, Editor & Yegin  Expires August 11, 2007             [Page 19]


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