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

Versions: 00 01 02 draft-ietf-mip6-radius

Network Working Group                                       K. Chowdhury
Internet-Draft                                          Starent Networks
Expires: April 24, 2006                                          A. Lior
                                                     Bridgewater Systems
                                                           H. Tschofenig
                                                                 Siemens
                                                        October 21, 2005


                       RADIUS Mobile IPv6 Support
                   draft-chowdhury-mip6-radius-00.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 April 24, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   A Mobile IPv6 node requires a home agent address, a home address, and
   IPsec security association with its home agent before it can start
   utilizing Mobile IPv6 service.  RFC 3775 requires that some or all of
   these parameters are statically configured.  Ongoing work aims to
   make this information dynamically available to the mobile node.  An



Chowdhury, et al.        Expires April 24, 2006                 [Page 1]


Internet-Draft                                              October 2005


   important aspect of the Mobile IPv6 bootstrapping solution is to
   support interworking with existing authentication, authorization and
   accounting infrastructure.  This document defines the new attributes
   to facilitate Mobile IPv6 bootstrapping via a RADIUS infrastructure.
   This information exchange may take place as part of the initial
   network access authentication procedure or as part of a separate
   protocol exchange between the mobile node, the home agent and the AAA
   infrastructure.

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Terminology  . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.   Solution Overview  . . . . . . . . . . . . . . . . . . . . .   5
     3.1  Integrated Scenario  . . . . . . . . . . . . . . . . . . .   5
     3.2  Split Scenario . . . . . . . . . . . . . . . . . . . . . .   6
   4.   RADIUS Attribute Overview  . . . . . . . . . . . . . . . . .   8
     4.1  Home Agent Address Attribute . . . . . . . . . . . . . . .   8
     4.2  Home Agent FQDN Attribute  . . . . . . . . . . . . . . . .   8
     4.3  Home Link Prefix Attribute . . . . . . . . . . . . . . . .   8
     4.4  Home Address Attribute . . . . . . . . . . . . . . . . . .   8
     4.5  DNS Update Mobility Option Attribute . . . . . . . . . . .   8
   5.   RADIUS attributes  . . . . . . . . . . . . . . . . . . . . .   9
     5.1  Home Agent Address Attribute . . . . . . . . . . . . . . .   9
     5.2  Home Agent FQDN Attribute  . . . . . . . . . . . . . . . .  10
     5.3  Home Link Prefix Attribute . . . . . . . . . . . . . . . .  10
     5.4  Home Address Attribute . . . . . . . . . . . . . . . . . .  11
     5.5  DNS Update Mobility Option Attribute . . . . . . . . . . .  12
   6.   Message Flows  . . . . . . . . . . . . . . . . . . . . . . .  14
   7.   Mapping of the Requirements  . . . . . . . . . . . . . . . .  15
   8.   Table of Attributes  . . . . . . . . . . . . . . . . . . . .  16
   9.   Security Considerations  . . . . . . . . . . . . . . . . . .  17
   10.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  18
   11.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  19
   12.  References . . . . . . . . . . . . . . . . . . . . . . . . .  20
     12.1   Normative References . . . . . . . . . . . . . . . . . .  20
     12.2   Informative References . . . . . . . . . . . . . . . . .  20
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  21
        Intellectual Property and Copyright Statements . . . . . . .  22












Chowdhury, et al.        Expires April 24, 2006                 [Page 2]


Internet-Draft                                              October 2005


1.  Introduction

   Mobile IPv6 specification [RFC3775] requires a Mobile Node (MN) to
   perform registration with a Home Agent with information about its
   current point of attachment (Care-of Address).  The Home Agent
   creates and maintains binding between the MN's Home Address and the
   MN's Care-of Address.

   In order to register with a Home Agent, the MN needs to know some
   information such as, the Home Link prefix, the Home Agent Address,
   the Home Address, the Home Link prefix Length and security related
   information in order to secure the Binding Update.

   The aforementioned set of information may be statically provisioned
   in the MN.  However, static provisioning of this information has its
   drawbacks.  It increases provisioning and network maintenance burden
   for the operator.  Moreover, static provisioning does not allow load
   balancing, failover, opportunistic home link assignment etc.  For
   example, the user may be accessing the network from a location that
   may be geographically far away from the preconfigured home link; the
   administrative burden to configure the MN's with the respective
   addresses is large and the ability to react on environmental changes
   is minimal.  In these situations static provisioning may not be
   desirable.

   Dynamic assignment of Mobile IPv6 home registration information is a
   desirable feature for ease of deployment and network maintenance.
   For this purpose, the RADIUS infrastructure, which is used for access
   authentication, can be leveraged to assign some or all of the
   necessary parameters.  The RADIUS server in the Access Service
   Provider (ASP) or in the Mobility Service Provider's (MSP) network
   may return these parameters to the AAA client.  The AAA client might
   either be the NAS, in case of the integrated scenario, or the home
   agent, in case of the split scenario.  The terms integrated and split
   are described in the terminology section and were introduced in
   [BOOT-PS].















Chowdhury, et al.        Expires April 24, 2006                 [Page 3]


Internet-Draft                                              October 2005


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 [BOOT-PS], 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, et al.        Expires April 24, 2006                 [Page 4]


Internet-Draft                                              October 2005


3.  Solution Overview

   This document addresses the authentication, authorization and
   accounting functionality required by for the MIPv6 bootstrapping as
   outlined in the MIPv6 bootstrapping problem statement document (see
   [BOOT-PS]).  As such, the AAA functionality for the integrated and
   the split scenario needs to be defined.  This requires the ability to
   offer support for the home agent to AAA server and the network access
   server to AAA server communication.

   To highlight the main use cases, we briefly describe the integrated
   and the split scenarios in Section 3.1 and Section 3.2, respectively.

3.1  Integrated Scenario

   In the integrated scenario MIPv6 bootstrapping is provided as part of
   the network access authentication procedure.  Figure 1 shows the
   participating entity.


                      +---------------------------+  +-----------------+
                      |Access Service Provider    |  |ASA/MSA/(/MSP)   |
                      |(Mobility Service Provider)|  |                 |
                      |                           |  |    +-------+    |
                      | +-------+                 |  |    |Remote |    |
                      | |Local  |          RADIUS |  |    |RADIUS |    |
                      | |RADIUS |-------------------------|Server |    |
                      | |Proxy  |                 |  |    +-------+    |
                      | +-------+                 |  |        ^        |
                      |     ^                     |  |        |RADIUS  |
                      |     |                     |  |        |        |
                      |     |                     |  |        v        |
                      |     |RADIUS               |  |    +-------+    |
                      |     |           +-------+ |  |    |Local  |    |
                      |     |    RADIUS |Home   | |  |    |Home   |    |
                      |     |    +----->|Agent  | |  |    |Agent  |    |
                      |     |    |      |in ASP | |  |    +-------+    |
                      |     v    v      +-------+ |  +-----------------+
   +-------+ IEEE     | +-----------+   +-------+ |
   |Mobile | 802.1X   | |NAS / Relay|   |DHCPv6 | |
   |Node   |----------+-|RADIUS     |---|Server | |
   |       | PANA,... | |Client     |   |       | |
   +-------+ DHCP     | +-----------+   +-------+ |
                      +---------------------------+


   Figure 1.  Mobile IPv6 service access in the integrated scenario




Chowdhury, et al.        Expires April 24, 2006                 [Page 5]


Internet-Draft                                              October 2005


   In the typical Mobile IPv6 access scenario as shown above, the MN
   attaches in a Access Service Provider's network.  During this network
   attachment procedure, the NAS/RADIUS client interacts with the mobile
   node.  As shown in Figure 1, the authentication and authorization
   happens via a RADIUS infrastructure.

   At the time of authorizing the user for IPv6 access, the RADIUS
   server in the MSA detects that the user is authorized for Mobile IPv6
   access.  Based on the MSA's policy, the RADIUS server may allocate
   several parameters to the MN for use during the subsequent Mobile
   IPv6 protocol interaction with the home agent.

   Depending on the details of the solution interaction with the DHCPv6
   server may be required, as described in [DHCP-INT].

3.2  Split Scenario

   In the split scenario, Mobile IPv6 bootstrapping is not provided as
   part of the network access authentication procedure.  The Mobile IPv6
   bootstrapping procedure is executed with the Mobility Service
   Provider when desired by the mobile node.  Two variations can be
   considered:

   a) the MSA and the MSP are the same entity.

   b) the MSA and the MSP are different entities.

   Since scenario (b) is the more generic scenario we show it in Figure
   2.






















Chowdhury, et al.        Expires April 24, 2006                 [Page 6]


Internet-Draft                                              October 2005


                                         +----------------------+
                                         |                      |
                                         |Mobility   +-------+  |
                                         |Service    |Remote |  |
                                         |Authorizer |RADIUS |  |
                                         |(MSA)      |Server |  |
                                         |           +-------+  |
                                         +---------------^------+
                                                         |
                                                         |RADIUS
                                                         |
                                                         |
                       +---------------------------------|------+
                       |Mobility Service Provider (MSP)  v      |
   +-------+           | +-----------+               +-------+  |
   |Mobile |  MIPv6 /  | |Home Agent/|     RADIUS    |Local  |  |
   |Node   |-------------|RADIUS     |-------------- |RADIUS |  |
   |       |  IKEv2    | |Client     |               |Proxy  |  |
   +-------+           | +-----------+               +-------+  |
                       +----------------------------------------+



   Figure 2.  Mobile IPv6 service access in the split scenario (MAS !=
   MSP)

   As shown in Fig. 2 the interaction between the RADIUS client and the
   RADIUS server is triggered by the protocol interaction between the
   mobile node and the home agent/RADIUS client using IKEv2 (see [BOOT-
   SPLIT]).  The home agent / RADIUS Client interacts with the RADIUS
   infrastructure to perform authentication, authorization, accounting
   and parameter bootstrapping.  The exchange is triggered by the home
   agent and an interaction with the RADIUS infrastructure is initiated.
   When the protocol exchange is completed then the home agent needs to
   possess the Mobile IPv6 specific parameters (see [BOOT-PS]).

   Additionally, the mobile node might instruct the RADIUS server (via
   the home agent) to perform a dynamic DNS update.













Chowdhury, et al.        Expires April 24, 2006                 [Page 7]


Internet-Draft                                              October 2005


4.  RADIUS Attribute Overview

4.1  Home Agent Address Attribute

   The RADIUs server may decide to assign a Home Agent to the MN that is
   in close proximity to the point of attachment (e.g., determined by
   the NAS-ID).  There may be other reasons for dynamically assigning
   Home Agents to the MN, for example to share the traffic load.  The
   attribute also contains the prefix length so that the MN can easily
   infer the Home Link prefix from the Home Agent address.

4.2  Home Agent FQDN Attribute

   The RADIUS server may assign an FQDN of the home address to the MN.
   The mobile node can perform DNS query with the FQDN to derive the
   home agent address.

4.3  Home Link Prefix Attribute

   For the same reason as the HA assignment, the RADIUS server may
   assign a Home Link that is in close proximity to the point of
   attachment (NAS-ID).  The MN can perform [RFC3775] specific
   procedures to discover other information for Mobile IPv6
   registration.

4.4  Home Address Attribute

   The RADIUS server may assign a Home Address to the MN.  This allows
   the network operator to support mobile devices that are not
   configured with static addresses.  The attribute also contains the
   prefix length so that the MN can easily infer the Home Link prefix
   from the Home Agent address.

4.5  DNS Update Mobility Option Attribute

   By using this payload the RADIUS client instructs the RADIUS server
   to perform a dynamic DNS update.  When this payload is included in
   the reverse direction, i.e., from the RADIUS server to the RADIUS
   client, it informs about the status of the dynamic DNS update.  When
   the payload is sent from the RADIUS client to the RADIUS server then
   the response MUST include the DNS Update Mobility Option attribute.










Chowdhury, et al.        Expires April 24, 2006                 [Page 8]


Internet-Draft                                              October 2005


5.  RADIUS attributes

   This section defines format and syntax for the attribute that carries
   the Mobile IPv6 parameters that are described in the previous
   section.

   The attributes MAY be present in Access-Accept, Accounting-Request.

5.1  Home Agent Address Attribute

   This attribute is sent by the RADIUS server to the NAS in an Access-
   Accept message.  The attribute carries the assigned Home Agent
   address.



       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      |    Reserved   | Prefix-Length |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                                                               |
      |              IPv6 address of assigned Home Agent              |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      Type:

         ASSIGNED-HA-ADDR-TYPE to be defined by IANA.

      Length:

         = 20 octets

      Reserved:

         Reserved for future use.  All bits set to 0.

      Prefix-Length:

         This field indicates the prefix length of the Home Link.

      IPv6 address of assigned Home Agent:





Chowdhury, et al.        Expires April 24, 2006                 [Page 9]


Internet-Draft                                              October 2005


         128-bit IPv6 address of the assigned Home Agent.


5.2  Home Agent FQDN Attribute

   This attribute is sent by the RADIUS server to the NAS in an Access-
   Accept message.  The attribute carries the FQDN of the assigned home
   agent.



       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      |            Reserved           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             FQDN of the assigned home agent                 ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      Type:

         ASSIGNED-HA-FQDN-TYPE to be defined by IANA.

      Length:

         Variable length.

      Reserved:

         Reserved for future use.  All bits set to 0.

      FQDN of the assigned home agent:

         The data field MUST contain a FQDN as described in [RFC1035].


5.3  Home Link Prefix Attribute

   This attribute is sent by the RADIUS-MIP server to the NAS in an
   Access-Accept message.  The attribute carries the assigned Home Link
   prefix.









Chowdhury, et al.        Expires April 24, 2006                [Page 10]


Internet-Draft                                              October 2005


       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      |            Reserved           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                                                               |
      |                       Home Link Prefix                        |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      Type:

         ASSIGNED-HL-TYPE to be defined by IANA.

      Length:

         >= 4 octets + the minimum length of a prefix.

      Reserved:

         Reserved for future use.  All bits set to 0.

      Home Link Prefix:

         Home Link prefix (upper order bits) of the assigned Home Link
         where the MN should send binding update.


5.4  Home Address Attribute

   This attribute is sent by the RADIUS server to the NAS in an Access-
   Accept message.  The attribute carries the assigned Home IPv6 Address
   for the MN.



       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      |   Reserved    | Prefix-Length |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                                                               |
      |                   Assigned IPv6 Home Address                  |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Chowdhury, et al.        Expires April 24, 2006                [Page 11]


Internet-Draft                                              October 2005


      Type:

         ASSIGNED-HOA-TYPE to be defined by IANA.

      Length:

         = 20 octets.

      Reserved:

         Reserved for future use.  All bits set to 0.

      Prefix-Length:

         This field indicates the prefix length of the Home Link.

      Assigned IPv6 Home Address:

         IPv6 Home Address that is assigned to the MN.


5.5  DNS Update Mobility Option Attribute

   The DNS Update Mobility Option attribute is used for triggering a DNS
   update by the RADIUS server and to return the result to the RADIUS
   client.  The request MUST carry the mobile node's FQDN but the
   attribute carried in response to the request MAY not carry a FQDN
   value.



       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      |   Reserved-1  |     Status    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |R| Reserved-2  |   FQDN                                       ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



      Type:

         DNS-UPDATE-TYPE to be defined by IANA.

      Length:





Chowdhury, et al.        Expires April 24, 2006                [Page 12]


Internet-Draft                                              October 2005


         Variable length.

      Reserved-1:

         Reserved for future use.  All bits set to 0.

      Status:

         This 8 bit unsigned integer field indicates the result of the
         dynamic DNS update procedure.  This field MUST be set to 0 and
         ignored by the RADIUS server when the DNS Update Mobility
         Option is sent from the RADIUS client to the RADIUS server.
         When the DNS Update Mobility Option is provided in the
         response, values of the Status field less than 128 indicate
         that the dynamic DNS update was performed successfully by the
         RADIUS server.  Values greater than or equal to 128 indicate
         that the dynamic DNS update was not successfully completed.
         The following values for the Status field are currently
         defined:

         0 DNS update performed

         128 Reason unspecified

         129 Administratively prohibited

         130 DNS Update Failed

      R flag:

         If this bit for the R flag is set then the RADIUS client
         requests the RADIUS server to remove the DNS entry identified
         by the FQDN included in this attribute.  If not set, the RADIUS
         client is requesting the RADIUS server to create or update a
         DNS entry with the FQDN specified in this attribute and the
         Home Address carried in another attribute specified in this
         document.

      Reserved-2:

         Reserved for future use.  All bits set to 0.

      FQDN of the mobile node:

         The data field MUST contain a FQDN as described in [RFC1035].






Chowdhury, et al.        Expires April 24, 2006                [Page 13]


Internet-Draft                                              October 2005


6.  Message Flows

   [Editor's Note: A future version of this document will provide
   example message flows.]















































Chowdhury, et al.        Expires April 24, 2006                [Page 14]


Internet-Draft                                              October 2005


7.  Mapping of the Requirements

   [Editor's Note: A future version of this document will map the
   requirements listed in [AAA-Goals]] with the solution provided in
   this document.]














































Chowdhury, et al.        Expires April 24, 2006                [Page 15]


Internet-Draft                                              October 2005


8.  Table of Attributes

   The following table provides a guide to which attributes may be found
   in RADIUS message and in what number.



   Request  Accept  Reject  Challenge    Attribute

   0-1        0-1     0       0          Home Agent Address Attribute
   0-1        0-1     0       0          Home Agent FQDN Attribute
   0-1        0-1     0       0          Home Link Prefix Attribute
   0-1        0-1     0       0          Home Address Attribute
   0-1        0-1     0       0          DNS Update Mobility Option
                                         Attribute


   The following table defines the meaning of the above table entries.

      0     This attribute MUST NOT be present.
      0-1   Zero or one instance of this attribute MAY be present.






























Chowdhury, et al.        Expires April 24, 2006                [Page 16]


Internet-Draft                                              October 2005


9.  Security Considerations

   Assignment of these values to a user should be based on successful
   authentication of the user at the NAS and/or at the home agent.  The
   RADIUS server should only assign these values to a user who is
   authorized for Mobile IPv6 service (this check could be performed
   with the user's subscription profile in the Home Network).

   The NAS and the home agent to the RADIUS server transactions must be
   adequately secured.  Otherwise there is a possibility that the user
   may receive fraudulent values from a rogue RADIUS server potentially
   hijacking the user's Mobile IPv6 session.

   These new attributes do not introduce additional security
   considerations besides the ones identified in [RFC2865].




































Chowdhury, et al.        Expires April 24, 2006                [Page 17]


Internet-Draft                                              October 2005


10.  IANA Considerations

   The following RADIUS attribute Type values MUST be assigned by IANA.

   ASSIGNED-HA-ADDR-TYPE

   ASSIGNED-HA-FQDN-TYPE

   ASSIGNED-HL-TYPE

   ASSIGNED-HOA-TYPE

   DNS-UPDATE-TYPE






































Chowdhury, et al.        Expires April 24, 2006                [Page 18]


Internet-Draft                                              October 2005


11.  Acknowledgements

   We would like to thank the following individuals for their review and
   constructive comments during the development of this document:

   Mark Watson, Jayshree Bharatia of Nortel.













































Chowdhury, et al.        Expires April 24, 2006                [Page 19]


Internet-Draft                                              October 2005


12.  References

12.1  Normative References

   [BOOT-SPLIT]
              Giaretta et. al., G., "Mobile IPv6 bootstrapping in split
              scenario.", draft-ietf-mip6-bootstrapping-split-00.txt
              (work in progress), June 2005.

   [DHCP-INT]
              Chowdhury et. al., K., "MIP6-bootstrapping via DHCPv6 for
              the Integrated Scenario.",
              draft-ietf-mip6-bootstrapping-integrated-DHC-00.txt (work
              in progress), October 2005.

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

12.2  Informative References

   [AAA-Goals]
              Giaretta et. al., G., "Goals for AAA-HA interface.",
              draft-ietf-mip6-aaa-ha-goals-00.txt (work in progress),
              April 2005.

   [BOOT-PS]  Patel et. al., A., "Problem Statement for bootstrapping
              Mobile IPv6.", draft-ietf-mip6-bootstrap-ps-03.txt (work
              in progress), July 2005.

   [MIP6-IKEv2]
              Devarapalli, V., "Mobile IPv6 Operation with IKEv2 and the
              revised IPsec.", draft-ietf-mip6-ikev2-ipsec-03.txt (work
              in progress), September 2005.

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

   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
              RFC 2136, April 1997.

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




Chowdhury, et al.        Expires April 24, 2006                [Page 20]


Internet-Draft                                              October 2005


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

   [RFC3776]  Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
              Protect Mobile IPv6 Signaling Between Mobile Nodes and
              Home Agents", RFC 3776, June 2004.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, March 2005.


Authors' Addresses

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

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


   Avi Lior
   Bridgewater Systems
   303 Terry Fox Drive, Suite 100
   Ottawa, Ontario
   Canada K2K 3J1

   Phone: +1 613-591-6655
   Email: avi@bridgewatersystems.com


   Hannes Tschofenig
   Siemens
   Otto-Hahn-Ring 6
   Munich, Bavaria  81739
   Germany

   Email: Hannes.Tschofenig@siemens.com










Chowdhury, et al.        Expires April 24, 2006                [Page 21]


Internet-Draft                                              October 2005


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


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




Chowdhury, et al.        Expires April 24, 2006                [Page 22]


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