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

Versions: 00

     Mobile IPv6                                                    J. Kempf
     Internet Draft                                          DoCoMo USA Labs
     Expires: October,2005                                    Feburary, 2005
     
     
     
          Extension to RFC 3775 for Alerting the Mobile Node to Home Agent
                                   Unavailability
                          draft-kempf-mip6-ha-alert-00.txt
     
     
     Status of this Memo
     
        By submitting this Internet-Draft, I certify that any applicable
        patent or other IPR claims of which I am aware have been disclosed,
        and any of which I become aware will be disclosed, in accordance with
        RFC 3668.
     
        Internet-Drafts are working documents of the Internet Engineering
        Task Force (IETF), its areas, and its working groups.  Note that
        other groups may also distribute working documents as Internet-
        Drafts.
     
        Internet-Drafts are draft documents valid for a maximum of six months
        and may be updated, replaced, or obsoleted by other documents at any
        time.  It is inappropriate to use Internet-Drafts as reference
        material or to cite them other than as "work in progress."
     
        The list of current Internet-Drafts can be accessed at
             http://www.ietf.org/ietf/1id-abstracts.txt
     
        The list of Internet-Draft Shadow Directories can be accessed at
             http://www.ietf.org/shadow.html
     
        This Internet-Draft will expire on July 28, 2005.
     
     Copyright Notice
     
           Copyright (C) The Internet Society (2004).  All Rights Reserved.
     
     Abstract
     
        RFC 3775 contains no way for a home agent to notify a mobile node
        that the home agent will shortly become unavailable, and suggest
        possible substitutes. A mobile node can suddenly find itself without
        mobility service. This document describes a simple protocol to inform
        the mobile node when its home agent is about to become unavailable
     
     
     
     
     Kempf                   Expires October, 2005                  Page [1]
     
     Internet-Draft    Home Agent Unavailability Alerting     Feburary, 2005
     
     
        and whether the mobile node should re-run bootstrapping to find a new
        home agent.
     
     Conventions used in this document
     
        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
        document are to be interpreted as described in RFC-2119 [1].
     
     Table of Contents
     
     
        1. Introduction...................................................2
        2. Scenarios......................................................3
           2.1. Periodic Maintenance......................................3
           2.2. Functional Load Balancing.................................3
           2.3. Home Agent Renumbering....................................4
        3. Home Agent Unavailability Message..............................4
           3.1. Validation of HAU Messages................................4
           3.2. Home Agent Unavailability Message Format..................5
        4. Home Agent Considerations......................................6
        5. Mobile Node Considerations.....................................6
        6. Security Considerations........................................7
        7. Open Questions.................................................7
        8. References.....................................................8
           8.1. Normative References......................................8
           8.2. Informative References....................................8
        Author's Addresses................................................8
        Intellectual Property Statement...................................8
        Disclaimer of Validity............................................9
        Copyright Statement...............................................9
        Acknowledgment....................................................9
     
     1. Introduction
     
        RFC 3775 [2] contains no protocol to allow a home agent to inform its
        mobile nodes that it is about to cease service. Without such
        functionality, a mobile node can suddenly find itself without its
        tunneled traffic. Even worse, if the mobile node is route optimizing,
        it may not discover the problem until much later, after other nodes
        fail to contact it.
     
        Note that, as a router on the home link, the home agent can use an
        unmodified RFC 2461 [2] Redirect to tell the mobile node about a new
        router on the home link, but the message is ambiguous. Is the
        recommended router a home agent or it just a router only for nodes on
        the home link? What if the entire link is going down? RFC 2461 only
     
     
     Kempf                   Expires October, 2005                  [Page 2]


     Internet-Draft    Home Agent Unavailability Alerting     Feburary, 2005
     
     
        allows routers to be referred to by their link local address in
        Redirects, which would not allow a mobile node away from home to find
        the new home agent. A home agent can also send a Router Advertisement
        with lifetime zero to indicate that it was becoming unavailable, but
        this would not provide the mobile node with any indication of a
        suggested substitute.
     
        In this document, a simple extension of the RFC 3775 Home Agent
        Discovery message is proposed to allow home agent unavailability
        alerting. The extension allows a home agent to send an unsolicited
        Home Agent Discovery message to inform the mobile node about the need
        to find a new home agent.
     
     2. Scenarios
     
        Here are a few sample scenarios where a home agent unavailability
        alerting message would be useful.
     
     2.1. Periodic Maintenance
     
        Although many users and engineers would prefer that networking
        equipment run without ever shutting down, most responsible service
        providers do periodic maintenance in order to maintain reliability.
        If a home agent is shut down for maintenance, some way is required to
        tell the client mobile nodes so they don't lose mobility service.
     
     2.2. Functional Load Balancing
     
        A Mobile IPv6 home agent provides the client with two basic services:
        a rendezvous server where correspondents can find the current care of
        address for the mobile node, and - when route optimization isn't used
        - an overlay router to redirect traffic sent to/from the home address
        to/from the care of address. A mobility service provider could have
        two sets of home agents to handle the two functions. The rendezvous
        function could be handled by a machine specialized for high speed
        transaction processing, while the overlay router function could be
        handled by a machine with high data throughput.
     
        A mobile node would start on the rendezvous server-like home agent
        and stay there if it does route optimization. However, if the
        original home agent detects that the mobile node isn't doing route
        optimization, it could redirect the mobile node to a home agent with
        better data throughput (of course, any existing TCP sessions would be
        dropped).
     
     
     
     
     
     Kempf                   Expires October, 2005                  [Page 3]


     Internet-Draft    Home Agent Unavailability Alerting     Feburary, 2005
     
     
     2.3. Home Agent Renumbering
     
        Periodically, a mobility service provider may want to shut down home
        agent service at a set of IPv6 addresses and bring service back up at
        a new set of addresses. Note that this may not involve anything as
        complex as IPv6 network renumbering, it may just involve changing the
        addresses on the home agents. There are various reasons why a
        mobility service provider might want to do this; an example is if the
        mobility service provider revokes the account of a user who the
        service provider has reason to believe might use the old home agent
        address to disrupt service for other users. With a service
        unavailability message, the service provider could inform mobile
        nodes to look for a new home agent.
     
     3. Home Agent Unavailability Message
     
        A home agent sends a Home Agent Unavailability (HAU) message when an
        anticipated period of unavailability occurs for the home agent. The
        message is sent to the mobile node's home address and is tunneled to
        the mobile node at its care of address.
     
     3.1. Validation of HAU Messages
     
        A mobile node MUST silently discard a received HAU message that does
        not satisfy all of the following validity checks:
     
              - IP Source Address is the global home agent address
     
              - The message is covered by the IPsec ESP SAs for ICMP messages
                between the home agent and mobile node.
     
              - IP Destination Address is the mobile node's home address.
     
              - ICMP Checksum is valid.
     
              - ICMP Code is TBD.
     
              - ICMP length (derived from the IP length) is 8 or more octets.
     
              - All included options have a length that is greater than
                zero.
     
        The contents of the Reserved field, and of any unrecognized options
        MUST be ignored.
     
     
     
     
     
     Kempf                   Expires October, 2005                  [Page 4]


     Internet-Draft    Home Agent Unavailability Alerting     Feburary, 2005
     
     
     3.2. Home Agent Unavailability Message Format
     
        Home agents send HAU packets to inform mobile node clients about
        pending periods of unavailability.  The home agent can recommend a
        list of substitute home agent addresses, or it can require the mobile
        node to re-initiate bootstrapping to find a new home agent by setting
        the length of the substitute list to zero.
     
         0                   1                   2                   3
     
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     Type      |     Code      |          Checksum             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |          Reserved             |    Number of Addresses        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |
        +                   Home Agent Address List...
        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |   Options ...
        +-+-+-+-+-+-+-+-+-+-+-+-
     
     
     
           IP Fields:
     
              Source Address
     
                             MUST be the home agent's global address.
     
              Destination Address
     
                             MUST be the mobile node's home address.
     
              ESP Header
     
                             The packet MUST be protected by an ESP tunnel
                             mode header for data origin authentication and
                             encryption, used to protect ICMP packets between
                             the home agent and mobile node.
     
           ICMP Fields:
     
              Type           145
     
     
     
     Kempf                   Expires October, 2005                  [Page 5]


     Internet-Draft    Home Agent Unavailability Alerting     Feburary, 2005
     
     
              Code           TBD (assigned by IANA)
     
              Checksum       The ICMP checksum
     
              Reserved       This field is unused.  It MUST be initialized to
                             zero by the sender and MUST be ignored by the
                             receiver.
     
              Number of Addresses
     
                             An unsigned integer giving the number of IPv6
                             home agent addresses in the list to follow. If
                             zero, then the mobile node MUST redo home agent
                             discovery.
     
              Home Agent Address List
     
                             List of 128 bit IPv6 addresses for suggested
                             substitute home agents.
     
        Possible Options:
     
        There are no default options. Options can be added by extension.
     
     4. Home Agent Considerations
     
        A home agent SHOULD send a HAU message when a known period of
        unavailability is pending. The message MUST be sent to all mobile
        nodes with currently active bindings. If alternative home agent
        addresses are known, either on the same subnet or a different one,
        the home agent SHOULD include them in the list of suggested
        substitute home agents. Otherwise, the home agent MUST set the length
        of the substitute home agent list to zero, forcing the mobile node to
        perform home agent discovery by some other means.
     
     5. Mobile Node Considerations
     
        Upon receipt of a HAU message, a mobile node MUST cease utilizing the
        old home agent for overlay traffic routing. If the HAU message
        contains a list of substitute home agents, the mobile node SHOULD
        select a home agent at random and establish the necessary IPsec
        security associations with the new home agent by whatever means
        required as part of the mobile node/home agent bootstrapping protocol
        for the home agent's mobility service provider. If no substitute home
        agents are included in the list, the mobile node MUST first perform
        home agent discovery.
     
     
     
     Kempf                   Expires October, 2005                  [Page 6]


     Internet-Draft    Home Agent Unavailability Alerting     Feburary, 2005
     
     
     6. Security Considerations
     
        As with other home link ICMP messages in RFC 3775, the HAU message
        MUST use the home agent to mobile node ESP encryption SA for
        confidentiality protection, and MUST use the home agent to mobile
        node ESP authentication SA for integrity protection.
     
        IANA Considerations
     
        A new ICMP Code, TBD, is required for the ICMP Home Agent Discovery
        message, type 145.
     
     7. Open Questions
     
              - If a home agent has a lot of clients, the IKE traffic and
                binding updates to the new home agent or agents could result
                in a lot of congestion. Would it make sense to enable a mode
                whereby the home agent can transfer the security and binding
                context to the new home agents, then set a flag in the HAU
                so that the mobile nodes don't have to re-initialize?
                Generally, transferring IPsec between hosts ("outside the
                crypto boundary") is strongly frowned upon by security
                folks, but one could make an argument that a distributed
                crypto boundary in which the machines share a strong
                security association could be set up. The other problem is
                what new home address to use. One could specify something
                simple, like the old interface identifier plus subnet prefix
                from the new home agent subnet, but that disallows subtle
                address allocation strategies such as CGA or RFC 3041
                address privacy. All in all, it seems like a hack. Sme kind
                of timing randomization on the initialization traffic would
                reduce the potential for congestion, but not the overall
                traffic volume.
     
              - If a home agent has lots of clients, it could end up
                unicasting lots of HAU messages, which could result in a lot
                of traffic and thus congestion. Would it make more sense to
                use a multicast message, perhaps to the All Nodes Multicast
                Address? Or should we introduce an All Mobile Nodes
                Multicast Address to avoid having fixed nodes on the subnet
                get the message? If multicast is used, then what security is
                on the packet? IPsec is for unicast only, so the ICMP SA
                can't be used.
     
              - Should the HAU include a "remaining lifetime" field,
                indicating how long the mobile node has before the home
                agent becomes unavailable?
     
     
     Kempf                   Expires October, 2005                  [Page 7]


     Internet-Draft    Home Agent Unavailability Alerting     Feburary, 2005
     
     
     8. References
     
     8.1. Normative References
     
        [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
              Levels", BCP 14, RFC 2119, March 1997.
     
        [2]   Johnson, D., Perkins, C., and Arkko, J., "Mobility Support in
              IPv6", RFC 3775, June, 2004.
     
        [3]   Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
              for IP Version 6 (IPv6)", RFC 2461, December 1998
     
     8.2. Informative References
     
     Author's Addresses
     
        James Kempf
        DoCoMo USA Labs
        181 Metro Drive
        Suite 300
        San Jose, CA
        95110
     
        Phone: +1 408 451 4711
        Email: kempf@docomolabs-usa.com
     
     
     Intellectual Property Statement
     
        The IETF takes no position regarding the validity or scope of any
        Intellectual Property Rights or other rights that might be claimed to
        pertain to the implementation or use of the technology described in
        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.
     
     
     
     
     Kempf                   Expires October, 2005                  [Page 8]


     Internet-Draft    Home Agent Unavailability Alerting     Feburary, 2005
     
     
        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.  By submitting this Internet-Draft, I certify that
        any applicable patent or other IPR claims of which I am aware have
        been disclosed, and any of which I become aware will be disclosed, in
        accordance with RFC 3668.
     
     Disclaimer of Validity
     
        This document and the information contained herein are provided on an
        "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
        OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
        ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
        INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
        INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
        WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
     
     Copyright Statement
     
        Copyright (C) The Internet Society (2004).  This document is subject
        to the rights, licenses and restrictions contained in BCP 78, and
        except as set forth therein, the authors retain all their rights.
     
     Acknowledgment
     
        Funding for the RFC Editor function is currently provided by the
        Internet Society.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Kempf                   Expires October, 2005                  [Page 9]
     

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