Internet DRAFT - draft-chowdhury-mip6-homeinfo-ra
draft-chowdhury-mip6-homeinfo-ra
Network Working Group K. Chowdhury
Internet-Draft Starent Networks
Expires: August 29, 2006 A. Patel
Cisco Systems
February 25, 2006
Home Info Discovery for Mobile IPv6 via ICMPv6 Router Advertisement
draft-chowdhury-mip6-homeinfo-ra-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 August 29, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
For Mobile IPv6 service, the mobile node first connects to an Access
Router and obtain an IPv6 address to use it as a Care-of-Address. In
many networks, the Access Router sends Router Advertisement to the
mobile node to convey various information. If the Access Router has
the knowledge of the mobile nodes home info such as home agent
address, the Access Router can convey that info to the mobile node
along with the Router Advertisement. This document proposes a method
Chowdhury & Patel Expires August 29, 2006 [Page 1]
Internet-Draft February 2006
that will allow the Access Router to include home info of the mobile
node in the Router Advertisement message.
Table of Contents
1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3
4. The ICMPv6 Options for Home Info . . . . . . . . . . . . . . . 5
4.1 IPv6 Home Link Prefix Option . . . . . . . . . . . . . . . 5
4.2 Home Agent IPv6 Address Option . . . . . . . . . . . . . . 6
5. Node Requirements . . . . . . . . . . . . . . . . . . . . . . 7
5.1 Mobile Node Requirements . . . . . . . . . . . . . . . . . 7
5.2 Access Router/NAS Requirements . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
9. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . 9
Chowdhury & Patel Expires August 29, 2006 [Page 2]
Internet-Draft February 2006
1. Introduction and Scope
Mobile IPv6 service [RFC3775] requires the Mobile Node to acquire a
Care-of Address (CoA) from the Access Router (AR) on the link where
it is currently attached. Moreover, the MN needs to have knowledge
of certain home network information such as address of the Home Agent
and the related Home Link Prefix (for Home Address auto-
configuration) prior to sending a Binding Update to register with the
Home Agent.
As part of the network attachment procedure in the current point of
attachment, the AR sends Router Advertisement (RA) (solicited or un-
solicited) to the MN to assist it in auto configuration of CoA an to
convey information about other link specific parameters [RFC2461],
[RFC2462]. It is possible that the AR has knowledge of the MN's home
network info at the time of sending the RA to the MN. Consider the
case when the NAS and the AR are collocated and the NAS received the
home network info such as HL prefix and the Home Agent address for
the MN from the Home AAA as part of the authentication and
authorization phase during layer 2 establishment. There may also be
cases, where the AR has the knowledge of the MN's home info via
provisioning or via other out of band methods.
Nevertheless, if the AR have the home network info for the MN it can
pass it to the MN via the RA that it sends to the MN. This certainly
speeds up the network connection setup process. This document
defines the ICMPv6 options that will carry such info in the RA. The
home info identified in the document are HL prefix and Home Agent
address. The defined format of the option is generic enough to carry
other information if needed in the future.
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].
3. Solution Overview
When the link between the MN and AR becomes enabled i.e. the bearer
path is open, the AR sends a Router Advertisement (RA) message to the
MN. The RA message is defined in [RFC2461]. If the AR already has
the MN's HL prefix and/or Home Agent address (either via pre-
configuration or retrieved earlier during AAA exchange for the link
establishment), it MUST include the same in corresponding options
(described in section 4) in the Router Advertisement message.
Chowdhury & Patel Expires August 29, 2006 [Page 3]
Internet-Draft February 2006
MN AR/NAS HAAA
| | |
(1) |-----Initiate layer 2----->| |
| connection | |
| | |
| (2)|---Layer 2 Auth Request--->|
| | |
| (3)|<----Layer 2 Auth Reply----|
| | (Send HL prefix |
| | and/or HA address) |
| | |
(4) |<-----Complete layer 2-----| |
| connection | |
| | |
(5) |----Router Solicitation--->| |
| (Optional) | |
| | |
(6) |<------Unicast Router------| |
| Advertisement | |
| (With the new | |
| HL prefix and/or | |
| HA address option) | |
| | |
Figure 1. Message flow for the proposed method with HAAA assist
Description of the steps:
1. The MN and the NAS begins L2 setup. As part of the L2
authentication and authorization process, either PPP LCP or EAP over
foo (where foo is specific link technology or PANA) is initiated.
2. The NAS exchanges AAA messages with the Home AAA (HAAA) to
authenticate and authorize the MN.
3. The NAS receives successful authentication indication from the
HAAA. As part of the authorization data, the HAAA sends HL prefix
and/or Home Agent information to the NAS.
4. The NAS and the MN completes L2 establishment.
5. At this step, the MN MAY send a Router Solicitation message to
begin L3 configuration process. However, this step is entirely
optional as the AR is not always waiting for the MN to send this
trigger to send an RA.
Chowdhury & Patel Expires August 29, 2006 [Page 4]
Internet-Draft February 2006
6. The AR sends a Router Advertisement to the MN. In this RA, the
AR includes the HL prefix info and/or the Home Agent address info in
the newly defined ICMPv6 options in this document. The AR and the
NAS are collocated in this solution. The AR identifies the proper
context in the NAS to extract home info by using the user ID that is
associated with the corresponding L2 connection over which the RA is
sent.
4. The ICMPv6 Options for Home Info
The following ICMPv6 options are proposed to carry the home info. At
this time two home info options are defined to carry HL prefix info
and Home Agent info respectively.
4.1 IPv6 Home Link Prefix Option
The IPv6 HL prefix info is sent via this option in the RA. The
format of the option is as follows:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
. .
. IPv6 Address prefix of the Home-Link .
. .
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
A 8-bit field indicating the type of the option. To be assigned
by IANA.
Code
0 (Zero).
Chowdhury & Patel Expires August 29, 2006 [Page 5]
Internet-Draft February 2006
Checksum
The ICMPv6 checksum.
IPv6 Address prefix of the Home-Link
The IPv6 prefix of the Home-Link assigned to the MN. The MN MAY
auto-configure and Home Address (HoA) using this prefix.
4.2 Home Agent IPv6 Address Option
The Home Agent IPv6 Address info is sent via this option in the RA.
The format of the option is as follows:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
. .
. IPv6 Home Agent Address (128-bits) .
. .
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
A 8-bit field indicating the type of the option. To be assigned
by IANA.
Code
0 (Zero).
Checksum
The ICMPv6 checksum.
IPv6 Address prefix of the Home-Link
The IPv6 Address of the Home Agent that is assigned to the MN.
Chowdhury & Patel Expires August 29, 2006 [Page 6]
Internet-Draft February 2006
5. Node Requirements
TBD.
5.1 Mobile Node Requirements
TBD.
5.2 Access Router/NAS Requirements
TBD.
6. Security Considerations
The MN MUST be able to trust the received RA from the Access Router.
This is a basic requirement for establishing connectivity in an IPv6
network. There are no additional security concerns applicable to the
solution proposed here.
7. IANA Considerations
The following Extension Types MUST be assigned by IANA:
IPv6 Home Link Prefix Option Type: TBD-1.
Home Agent IPv6 Address Option Type: TBD-2.
8. Acknowledgements
TBD.
9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
Chowdhury & Patel Expires August 29, 2006 [Page 7]
Internet-Draft February 2006
Authors' Addresses
Kuntal Chowdhury
Starent Networks
30 International Place
Tewksbury, MA 01876
US
Phone: +1 214-550-1416
Email: kchowdhury@starentnetworks.com
Alpesh Patel
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
US
Phone: +1 408-853-9580
Email: alpesh@cisco.com
Chowdhury & Patel Expires August 29, 2006 [Page 8]
Internet-Draft February 2006
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 (2006). 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 & Patel Expires August 29, 2006 [Page 9]
