One document matched: draft-navali-ip6-over-netmip4-00.txt
Network Working Group J. Navali
Internet-Draft K. Chowdhury
Expires: August 29, 2006 Starent Networks
February 25, 2006
IPv6 over Network based Mobile IPv4
draft-navali-ip6-over-netmip4-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
There is a growing demand for routable IP addresses to support large
wireless user base today. Wireless operators are looking for ways to
leverage the IPv6 address space to meet the ever increasing number of
wireless data users. The operators who has network based IPv4
mobility solutions can leverage the same scheme to provide mobility
access service with larger address pool using IPv6 addressing. This
document defines such a mechanism.
Navali & Chowdhury Expires August 29, 2006 [Page 1]
Internet-Draft February 2006
Table of Contents
1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3
3.1 IPv6 addressing via IPv6CP . . . . . . . . . . . . . . . . 3
3.1.1 IPv6 Addressing with unique HL prefix . . . . . . . . 4
3.1.2 IPv6 Addressing with shared HL prefix . . . . . . . . 7
3.2 IPv6 addressing via DHCPv6 . . . . . . . . . . . . . . . . 10
4. MIPv4 Message Enhancements . . . . . . . . . . . . . . . . . . 12
4.1 IPv6 Home Address Request Extension . . . . . . . . . . . 12
4.2 IPv6 Home Address Extension . . . . . . . . . . . . . . . 13
4.3 MIPv4 Registration Request and Reply . . . . . . . . . . . 14
4.4 MIPv4 Registration Revocation Procedures . . . . . . . . . 14
5. Node Requirements . . . . . . . . . . . . . . . . . . . . . . 14
5.1 Mobile Node Requirements . . . . . . . . . . . . . . . . . 15
5.2 Access Router/NAS/NetMIP4 Client/DHCP-proxy
Requirements . . . . . . . . . . . . . . . . . . . . . . . 15
5.2.1 IPv6 Addressing . . . . . . . . . . . . . . . . . . . 15
5.2.2 Authentication at the AR . . . . . . . . . . . . . . . 15
5.2.3 IPv6 Data processing . . . . . . . . . . . . . . . . . 15
5.3 Home Agent Requirements . . . . . . . . . . . . . . . . . 15
5.3.1 IPv6 Addressing . . . . . . . . . . . . . . . . . . . 15
5.3.2 Authentication at the HA . . . . . . . . . . . . . . . 16
5.3.3 IPv6 Data processing . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
9. Normative References . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . 19
Navali & Chowdhury Expires August 29, 2006 [Page 2]
Internet-Draft February 2006
1. Introduction and Scope
Mobile operators are running out of routable subscriber IPv4 address
space and are exploring ways to deploy IPv6 to leverage the expanded
128-bit address space. In the absence of native IPv6 support on the
IPv4 packet core network, a transition mechanism is needed to use the
IPv6 address space over existing IP core networks.
This document describes an approach to utilize network based IPv4
mobility solution to support tunneling of IPv6 traffic from an access
router to an IPv6 correspondent node via a dual stack home agent.
The scheme employs MIPv4 messages to obtain an IPv6 Home address
(HoA) or Home Link (HL) prefix from the home agent so that the access
router can assign an IPv6 address to an IPv6 mobile node. The access
router and the home agent establish an IPv6-over-IPv4 tunnel to carry
the IPv6 user traffic. The tunnel is extended to a default 6to4
gateway configured for the IPv6 address pool on the home agent. This
facilitates seamless IPv6 handset mobility across access routers
while keeping the same IPv6 address. On handoff, the new access
router will register the same IPv6 HoA with the home agent each time
with a different IPv4 care-of-address.
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].
The term NetMIPv4 used in this document refers to a Mobile IPv4
client that is implemented in a network node. This entity can
perform Mobile IPv4 registration on behalf of the Mobile Node.
3. Solution Overview
3.1 IPv6 addressing via IPv6CP
For networks that use PPP as the link layer between the mobile Node
(MN) and the Access Router (AR), the interface ID (IID) negotiation
is performed via IPv6CP [RFC2023].
Following successful IPv6CP negotiation and establishment of the
unique link-local address, the AR initiates Router Advertisement (RA)
messages using its link-local address as the source address, as per
[RFC2461]. The RA messages contain a prefix used by the MS to
configure global IPv6 addresses. The AR supports Interface
Identifier option negotiation. The AR generates local Interface
Identifier (for the local side of the PPP link) and Remote Interface
Identifier (for the Mobile side of the PPP link). The remote
Navali & Chowdhury Expires August 29, 2006 [Page 3]
Internet-Draft February 2006
Interface Identifier is assigned to the Mobile Node during IPv6CP
negotiation. The AR makes sure that the Interface Identifier is
unique over the PPP link. The Interface Identifier is used along
with the IPv6 HL prefix to construct the 128-bit IPv6 address for the
Mobile Node.
The ARs conformant to this specification shall behaves as follows:
Upon receiving an IPv6CP configure request with IID set to 0, the AR
shall initiate a MIPv4 registration request to the home agent using a
IPv4 FA-COA and request an IPv6 HoA or HL prefix from the home agent.
The HA shall assign unique IPv6 HoA or HL prefix to a mobile node
after successfully processing the registering request. The HoA or HL
prefix range may be configured as IPv6 pool with in HA.
After receiving the MIPv4 RRP from the home agent with a valid IPv6
HoA or HL prefix, the AR sends a Router Advertisement message which
contains the HL prefix received from the home agent. This is done
assuming that at this time the IPv6CP negotiation with the MN is over
and the PPP link has reached the NCP open state.
The AR and the home agent establish an IPv6-in-IPv4 tunnel using the
FA-COA IPv4 address, the home agent's IPv4 address and the IPv6 HoA
tuple. The IPv6 traffic from the mobile node is carried in this
IPv6-in-IPv4 tunnel to the home agent. The 6to4 tunneling or other
form of tunneling may be used to forward IPv6 data packets from the
mobile node to another IPv6 Router/Host over the intermediate IPv4
networks.
3.1.1 IPv6 Addressing with unique HL prefix
In this section we show a scenario where an IPv6 address is assigned
to the MN using an unique HL prefix:
Navali & Chowdhury Expires August 29, 2006 [Page 4]
Internet-Draft February 2006
+----+ +-------+ +-------+ +-----+
| | | | | | | |
| MN/| |NAS/ | | Home | |6to4 |
|User| |NetMIP4| | Agent | |Relay|
| | |Client/| | | | |
| | | FA | | | | |
+----+ +-------+ +-------+ +-----+
| | | |
| 1 | | |
|<------------->| | |
| | | |
| 2 | | |
|-------------->| | |
| | 3 | |
| 4 |------------>| |
|<--------------| | |
| | 5 | |
| |<------------| |
| 6 | | |
|<--------------| | |
| | | |
| 7 | | |
|-------------->| | |
| | | |
| 8 | | |
|-------------->| | |
| | | |
| 9 | | |
|<--------------| | |
| | | |
| 10 | | |
|-------------->| | |
| | | |
| 11 | | |
|<--------------| | |
| | | |
| | | |
Auto Config 12 | | |
IPv6 address | | |
| | | |
| 13 | | |
|<------------->|<===========>|<========>|
| | | |
Figure 1. IPv6 Addressing with unique HL prefix
Navali & Chowdhury Expires August 29, 2006 [Page 5]
Internet-Draft February 2006
Description of the steps:
1. MN and the NAS performs LCP phase. During this phase, the MN may
run CHAP or PAP. The NAS may authenticate the MN via an AAA
infrastructure (not shown here). At this step the AR (NAS) may
receive a home agent address that should be used as the home agent to
acquire an HoA/HL prefix for the MN.
2. The MN sends an IPv6CP config request with IID set to any number.
3. The AR (NetMIP4 Client) assigns an IID for the MN. It sends a
MIP4 RRQ to the home agent (either configured in the AR or received
from the AAA server at step 1). The RRQ includes the assigned IID
for the MN in a HoA request extension. The RRQ has the CoA field set
to the FA-CoA of the AR.
4. The AR/NAS sends an IPv6CP config request to configure the IID
that it wants to use for the IPv6 Link Local address.
5. The home agent registers the MN's session and assigns an HoA.
The home agent constructs the HoA based on the received IID (lower 64
bits) with an unique prefix (upper 64-bits). The home agent may
perform proxy DAD on the newly formed HoA. Assuming proxy DAD
produces no response, the home agent returns the HoA in the RRP.
6. The AR/NAS responds back to the MN with an IPv6CP config-NAK to
suggest the IID that it wants the MN to use for link local address.
This happens in response to step 2.
7. The MN sends back an IPv6CP config-ACK to acknowledge the IID
that the AR/NAS proposed in step 4 that it would use.
8. The MN sends an IPv6CP config request to the AR/NAS with the IID
that was assigned by the AR/NAS in step 6.
9. The AR/NAS sends back an IPv6CP config-ACK to the MN in response
to step 8.
10. At this stage the MN and the AR/NAS PPP state machine should be
in NCP open state. The MN sends an Router Solicitation to the AR.
11. The AR responds with an Router Advertisement that contains a
prefix set to the home link prefix of the HoA that was received at
step 5.
12. The MN autoconfigures the IPv6 address with the IID and the
prefix from step 9 and step 11.
Navali & Chowdhury Expires August 29, 2006 [Page 6]
Internet-Draft February 2006
13. The MN's IPv6 traffic is tunneled by the AR to the HA via an
v6overv4 tunnel and the HA tunnels the packets via another tunnel
(6to4 in this illustration) to the v6 node/domain.
3.1.2 IPv6 Addressing with shared HL prefix
In this section we show a scenario where an IPv6 address is assigned
to the MN using a shared HL prefix:
Navali & Chowdhury Expires August 29, 2006 [Page 7]
Internet-Draft February 2006
+----+ +-------+ +-------+ +-----+
| | | | | | | |
| MN/| |NAS/ | | Home | |6to4 |
|User| |NetMIP4| | Agent | |Relay|
| | |Client/| | | | |
| | | FA | | | | |
+----+ +-------+ +-------+ +-----+
| | | |
| 1 | | |
|<------------->| | |
| | | |
| 2 | | |
|-------------->| | |
| | 3 | |
| 4 |------------>| |
|<--------------| | |
| | 5 | |
| |<------------| |
| 6 | | |
|<--------------| | |
| | | |
| 7 | | |
|-------------->| | |
| | | |
| 8 | | |
|-------------->| | |
| | | |
| 9 | | |
|<--------------| | |
| | | |
| 10 | | |
|-------------->| | |
| | | |
| 11 | | |
|<--------------| | |
| | | |
| | | |
Auto Config 12 | | |
IPv6 address | | |
| | | |
| 13 | | |
|<------------->|<===========>|<========>|
| | | |
Figure 1. IPv6 Addressing with shared HL prefix
Navali & Chowdhury Expires August 29, 2006 [Page 8]
Internet-Draft February 2006
Description of the steps:
1. MN and the NAS performs LCP phase. During this phase, the MN may
run CHAP or PAP. The NAS may authenticate the MN via an AAA
infrastructure (not shown here). At this step the AR (NAS) may
receive a home agent address that should be used as the home agent to
acquire an HoA/HL prefix for the MN.
2. The MN sends an IPv6CP config request with IID set to any number.
3. in this case, the AR (NetMIP4 Client) does not assigns an IID for
the MN. It sends a MIP4 RRQ to the home agent (either configured in
the AR or received from the AAA server at step 1). The RRQ includes
IID=0 in a HoA request extension. The RRQ has the CoA field set to
the FA-CoA of the AR.
4. The AR/NAS sends an IPv6CP config request to configure the IID
that it wants to use for the IPv6 Link Local address.
5. The home agent registers the MN's session and assigns an HoA.
The home agent assigns an HoA for the MN from its pool. Since the
home agent is the custodian of the HoA (128-bits) it can use a HL
prefix that is shared among number of registered MNs, there may not
be a need to run proxy DAD for the assigned HoA in this case. The
home agent returns the HoA in the RRP.
6. The AR/NAS extracts the IID and the HL prefix from the received
IPv6 HoA extension in the RRP (step 5). The AR/NAS responds back to
the MN with an IPv6CP config-NAK to suggest this IID. This
happens in response to step 2.
7. The MN sends back an IPv6CP config-ACK to acknowledge the IID
that the AR/NAS proposed in step 4 that it would use.
8. The MN sends an IPv6CP config request to the AR/NAS with the IID
that was assigned by the AR/NAS in step 6.
9. The AR/NAS sends back an IPv6CP config-ACK to the MN in response
to step 8.
10. At this stage the MN and the AR/NAS PPP state machine should be
in NCP open state. The MN sends an Router Solicitation to the AR.
11. The AR responds with an Router Advertisement that contains a
prefix set to the home link prefix of the HoA (extracted at step 6)
that was received at step 5.
12. The MN autoconfigures the IPv6 address with the IID and the
Navali & Chowdhury Expires August 29, 2006 [Page 9]
Internet-Draft February 2006
prefix from step 9 and step 11.
13. The MN's IPv6 traffic is tunneled by the AR to the HA via an
v6overv4 tunnel and the HA tunnels the packets via another tunnel
(6to4 in this illustration) to the v6 node/domain.
3.2 IPv6 addressing via DHCPv6
For networks that use DHCPv6 for IPv6 address configuration, the MN
and the AR exchanges DHCPv6 messages for this purpose. In this
section we describe the method via which the AR/NetMIPv4 Client
acquires an HoA for the MN.
It is assumed in this solution that the AR/NAS/FA, NetMIPv4 Client
and the DHCP server (sort of a DHCP proxy) are collocated.
The ARs conformant to this specification shall behaves as follows:
Upon receiving an DHCP REQUEST from the MN (DHCP Client), the AR
shall initiate a MIPv4 registration request to the home agent using a
IPv4 FA-COA and request an IPv6 HoA or HL prefix from the home agent.
The HA shall assign unique IPv6 HoA or HL prefix to a mobile node
after successfully processing the registering request. The HoA or HL
prefix range may be configured as IPv6 pool with in HA.
After receiving the MIPv4 RRP from the home agent with a valid IPv6
HoA or HL prefix, the AR sends a DHCP REPLY message which contains
the HoA received from the home agent.
The AR and the home agent establish an IPv6-in-IPv4 tunnel using the
FA-COA IPv4 address, the home agent's IPv4 address and the IPv6 HoA
tuple. The IPv6 traffic from the mobile node is carried in this
IPv6-in-IPv4 tunnel to the home agent. The 6to4 tunneling or other
form of tunneling may be used to forward IPv6 data packets from the
mobile node to another IPv6 Router/Host over the intermediate IPv4
networks.
The following call flow illustrates the IPv6 addressing with DHCPv6:
Navali & Chowdhury Expires August 29, 2006 [Page 10]
Internet-Draft February 2006
+----+ +-------+ +-------+ +-----+
| | | | | | | |
| MN/| |NAS/ | | Home | |6to4 |
|User| |NetMIP4| | Agent | |Relay|
| | |Client/| | | | |
| | | FA/ | | | | |
| | |DHCP- | | | | |
| | | proxy | | | | |
+----+ +-------+ +-------+ +-----+
| | | |
| 1 | | |
|<------------->| | |
| | | |
| 2 | | |
|-------------->| | |
| | 3 | |
| |------------>| |
| | | |
| | 4 | |
| |<------------| |
| 5 | | |
|<--------------| | |
| | | |
| | | |
| 6 | | |
|<------------->|<===========>|<========>|
| | | |
Figure 1. Message flow for DHCPv6 based IPv6 addressing w/ NetMIP4
Description of the steps:
1. MN and the NAS performs access authentication and authorization
e.g. EAP. The NAS acting as the EAP authenticator authenticates the
MN via an AAA infrastructure (not shown here). At this step the AR
(NAS) may receive a home agent address that should be used as the
home agent to acquire an HoA prefix for the MN.
2. The MN sends an DHCP REQUEST message to the AR/DHCP-proxy. It is
assumed that the MN has discovered the DHCP-proxy address either via
a SOLICIT message or an ADVERTISE message from the DHCP-proxy. These
messages are not shown in this call flow.
3. The AR (NetMIP4 Client) sends a MIP4 RRQ to the home agent
(either configured in the AR or received from the AAA server at step
Navali & Chowdhury Expires August 29, 2006 [Page 11]
Internet-Draft February 2006
1). The RRQ includes IID=0 in a HoA request extension.
4. The home agent registers the MN's session and assigns an HoA.
The home agent assigns an HoA for the MN from its pool. Since the
home agent is the custodian of the HoA (128-bits) it can use a HL
prefix that is shared among number of registered MNs, there may not
be a need to run proxy DAD for the assigned HoA in this case. The
home agent returns the HoA in the RRP.
5. The AR/NAS responds back to the MN with an DHCP REPLY message
containing the assigned HoA to the MN.
6. The MN's IPv6 traffic is tunneled by the AR to the HA via an
v6overv4 tunnel and the HA tunnels the packets via another tunnel
(6to4 in this illustration) to the v6 node/domain.
4. MIPv4 Message Enhancements
The following extensions are defined to exchange the Interface-ID and
IPv6 HoA information between the AR and HA. Note that any known and
previously authenticated username(e.g the username that was
authenticated during EAP or LCP) can be used as the NAI for the
MIPv4 session and sent in the MN-NAI extension. If PPP/EAP username
is not available, then another identifier will be needed to identify
the session. In some wireless networks It is possible to use the
MSID of a subscriber or the hardware ID (e.g. MAC address) of the MN
to identify the session, carried in the MN-NAI extension.
4.1 IPv6 Home Address Request Extension
The IPv6 Home Address Request Extension conforms to the Short
Extension format specified for Mobile IPv4 [RFC3344]. The IPv6 Home
Address Request Extension is not a skippable extension. The format
of the extension 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 | Length | Sub-Type | IID ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
A 8-bit field indicating the type of the extension. To be
assigned by IANA.
Navali & Chowdhury Expires August 29, 2006 [Page 12]
Internet-Draft February 2006
Length
A 8-bit field indicating the length of the option. Set to 11.
Sub-Type
A 8-bit field not used in this extension. It is set to 0.
IID
A 64-bit field set to the Interface ID allocated by the AR for the
MN.
Note that the IPv6 Home Address Request Extension is included by the
AR only in the initial RRQ messages sent to HA.
When the AR has locally assigned an Interface-ID to the MN, it
includes the non-zero Interface-ID (64-bits) in this extension to
request HA to assign a unique Home Link Prefix. If the AR expects
the HA to assign a Home Address (including Interface-ID), then the AR
sets the Interface-ID in this extension to zero.
4.2 IPv6 Home Address Extension
The IPv6 Home Address Extension may be included in the RRQ from the
AR or in the RRP from the HA to identify a MIP registration. Note
that this may also be included in MIPv4 Revocation and Acknowledgment
messages [RFC3543] for the same purpose. The format of the extension
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 | Length |U| Reserved | IPv6 HoA ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
A 8-bit field indicating the type of the extension. To be
assigned by IANA.
Length
A 8-bit field indicating the length of the option. Set to 19.
Navali & Chowdhury Expires August 29, 2006 [Page 13]
Internet-Draft February 2006
U
When set this indicates the uniqueness of the HL prefix used to
construct the HoA.
Reserved
Set to 0s.
IPv6 HoA
A 128-bit field set to the IPv6 address (HoA) allocated by the HA
for the MN.
4.3 MIPv4 Registration Request and Reply
For any MN that was assigned an IPv6 Home Address via NetMIPv4, the
MIPv4 Registration Request from the AR may include one of the
following extensions depending upon the type of request.
The IPv6 Home Address Request Extension is included in initial
registration request from the AR to the HA for session setup.
The IPv6 Home Address Extension is included in renewal and de-
registration requests from the AR to the HA. It is also included in
all Registration Reply messages from the HA.
The IPv6 Home Address Request Extension and the IPv6 Home Address
Extension must be included before the FA-HA Authentication Extension.
4.4 MIPv4 Registration Revocation Procedures
For any MN that was assigned an IPv6 Home Address via NetMIPv4, the
MIPv4 Registration Revocation and Revocation Acknowledgment messages
[RFC3543] from the AR or the HA should include the IPv6 Home Address
Extension to identify the MIP registration correctly.
The IPv6 Home Address Extension must be included before the FA-HA
Authentication Extension. Note that the AR sends a deregistration
Request (lifetime = 0) to terminate a binding at the HA and not a
Revocation message and the HA responds with a Deregistration Reply.
The HA sends a Revocation message to terminate a binding at the AR
and the AR responds with an Acknowledgment message.
5. Node Requirements
This section describes the requirements for each of the nodes
involved in this method.
Navali & Chowdhury Expires August 29, 2006 [Page 14]
Internet-Draft February 2006
5.1 Mobile Node Requirements
Mobile node behavior shall conform to the IPv6 specification defined
in [RFC2472], [RFC2460], [RFC2461], [RFC2462], [RFC3315]. The
Interface-Identifier is assigned by the AR to the Mobile during
IPv6CP negotiation in case the MN uses IPv6 over PPP. The HL prefix
is assigned to the mobile in the Router Advertisement message.
5.2 Access Router/NAS/NetMIP4 Client/DHCP-proxy Requirements
5.2.1 IPv6 Addressing
If the MN needs to be assigned a unique HL Prefix, the AR assigns an
Interface-ID locally, and initiates NetMIP4 procedures to the HA.
The AR sends a RRQ to HA including the IPv6 Home Address Request
Extension with the Interface-ID set to the assigned Interface-ID.
If the MN does not need a unique HL prefix, the AR initiates NetMIP4
procedures to the HA when IPv6CP Conf-Req is received from the MN.
The AR sends a RRQ to HA including the IPv6 Home Address Request
Extension with the Interface-ID set to zero.
When a RRP (Accepted) with IPv6 Home Address Extension is received
with a valid home address, the AR extracts the HL prefix from the
HoA. The AR indicates the HL Prefix to the MN via a Router
Advertisement message and puts the MN in connected state.
5.2.2 Authentication at the AR
The PPP CHAP or PAP or EAP authentication shall be performed for IPv6
network access. For NetMIP4 procedures, the MN-HA, MN-FA, FA-HA
authentication keys can be made available at the NetMIP4 Client via a
key distribution scheme that is implemented at the AR. All RRQ/RRP
messages must be protected by the FA-HA Authentication Extension.
The key distribution method is outside the scope of this document.
5.2.3 IPv6 Data processing
When the AR receives an IPv6 PDU from the MN, the AR encapsulates the
packet in a IPv4 packet and forwards it to the HA. If the AR
receives an IPv4 encapsulated IPv6 PDU from the HA, it removes the
outer IPv4 header and forwards the IPv6 PDU to the MN.
5.3 Home Agent Requirements
5.3.1 IPv6 Addressing
The HA needs to be configured with either IPv6 prefix pools or IPv6
Navali & Chowdhury Expires August 29, 2006 [Page 15]
Internet-Draft February 2006
address pools. If Interface-ID is assigned at the AR, the HA cannot
assign shared HL prefix; it has to be a unique HL prefix per MN.
When a RRQ is received with IPv6 Home Address Request Extension that
has a non-zero Interface-ID in it, the HA assigns a HL prefix to the
MN, forms the global IPv6 address for the MN using the received
Interface-ID and sends a Reply with IPv6 Home Address Extension.
When a RRQ is received with IPv6 Home Address Request Extension with
Interface-ID set to zero, the HA assigns a IPv6 Home address to the
MN, and sends a Reply with IPv6 Home Address Extension.
If the Interface-ID is assigned at the HA, the HA can choose to
assign a shared or unique HL prefix per MN. Optionally the HA can
assign a unique HL prefix to the MN also. The HA sets the Unique HL
prefix bit "U" in the Home Address Extension to indicate this.
5.3.2 Authentication at the HA
For NetMIP4 procedures, the MN-HA, FA-HA authentication keys can be
made available at the Home Agent via a key distribution scheme that
is implemented at the HA. All RRQ/RRP messages must be protected by
the FA-HA Authentication Extension. The key distribution method is
outside the scope of this document.
5.3.3 IPv6 Data processing
When the HA receives a IPv6 PDU over a 6to4 tunnel from the default
6to4router, it removes the IPv4 header and looks at the inner IPv6
address. If an tunnel has been established for this MN and there is
a binding cache entry for the same, the HA encapsulates the packet in
an IPv4 packet and forwards it to the AR. If the HA receives an IPv4
encapsulated IPv6 PDU from the AR, it removes the outer IPv4 header
and forwards the IPv6 PDU over the 6to4 tunnel to the default 6to4
router.
6. Security Considerations
The proposed method of acquiring IPv6 address via network based
Mobile IPv4 (NetMIP4) requires secure key generation and key
distribution for securing the RRQs and RRPs. Although this key
generation and distribution details are not part of this document, it
is necessary to put in place a solution for this to prevent rouge
network nodes to launch attacks on user's sessions.
There are several work going on in IETF which are based on EAP keying
framework. Also several SDOs are developing key distribution schemes
that can be leveraged for a solution.
Navali & Chowdhury Expires August 29, 2006 [Page 16]
Internet-Draft February 2006
7. IANA Considerations
The following Extension Types MUST be assigned by IANA:
IPv6 Home Address Request Extension Type: TBD-1.
IPv6 Home Address Extension Type: TBD-2.
8. Acknowledgements
TBD.
9. Normative References
[RFC2023] Haskin, D. and E. Allen, "IP Version 6 over PPP",
RFC 2023, October 1996.
[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.
[RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP",
RFC 2472, December 1998.
[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.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[RFC3543] Glass, S. and M. Chandra, "Registration Revocation in
Mobile IPv4", RFC 3543, August 2003.
Navali & Chowdhury Expires August 29, 2006 [Page 17]
Internet-Draft February 2006
Authors' Addresses
Jay Navali
Starent Networks
30 International Place
Tewksbury, MA 01876
US
Phone: +1 978-851-1141
Email: jnavali@starentnetworks.com
Kuntal Chowdhury
Starent Networks
30 International Place
Tewksbury, MA 01876
US
Phone: +1 214-550-1416
Email: kchowdhury@starentnetworks.com
Navali & Chowdhury Expires August 29, 2006 [Page 18]
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.
Navali & Chowdhury Expires August 29, 2006 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-24 03:22:50 |