draft-ietf-netlmm-pmip6-ipv4-support-14.txt   draft-ietf-netlmm-pmip6-ipv4-support-15.txt 
NETLMM Working Group R. Wakikawa NETLMM Working Group R. Wakikawa
Internet-Draft Toyota ITC Internet-Draft Toyota ITC
Intended status: Standards Track S. Gundavelli Intended status: Standards Track S. Gundavelli
Expires: January 14, 2010 Cisco Expires: February 24, 2010 Cisco
July 13, 2009 August 23, 2009
IPv4 Support for Proxy Mobile IPv6 IPv4 Support for Proxy Mobile IPv6
draft-ietf-netlmm-pmip6-ipv4-support-14.txt draft-ietf-netlmm-pmip6-ipv4-support-15.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 14, 2010. This Internet-Draft will expire on February 24, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 29 skipping to change at page 2, line 29
2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 8 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 8
2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 8 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8
3. IPv4 Home Address Mobility Support . . . . . . . . . . . . . . 10 3. IPv4 Home Address Mobility Support . . . . . . . . . . . . . . 10
3.1. Local Mobility Anchor Considerations . . . . . . . . . . . 11 3.1. Local Mobility Anchor Considerations . . . . . . . . . . . 11
3.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 11 3.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 11
3.1.2. Signaling Considerations . . . . . . . . . . . . . . . 11 3.1.2. Signaling Considerations . . . . . . . . . . . . . . . 11
3.1.3. Routing Considerations for the Local Mobility 3.1.3. Routing Considerations for the Local Mobility
Anchor . . . . . . . . . . . . . . . . . . . . . . . . 17 Anchor . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2. Mobile Access Gateway Considerations . . . . . . . . . . . 17 3.1.4. ECN & Payload Fragmentation Considerations . . . . . . 17
3.2. Mobile Access Gateway Considerations . . . . . . . . . . . 18
3.2.1. Extensions to Binding Update List Entry . . . . . . . 18 3.2.1. Extensions to Binding Update List Entry . . . . . . . 18
3.2.2. Extensions to Mobile Node's Policy Profile . . . . . . 18 3.2.2. Extensions to Mobile Node's Policy Profile . . . . . . 18
3.2.3. Signaling Considerations . . . . . . . . . . . . . . . 18 3.2.3. Signaling Considerations . . . . . . . . . . . . . . . 19
3.2.4. Routing Considerations for the Mobile Access 3.2.4. Routing Considerations for the Mobile Access
Gateway . . . . . . . . . . . . . . . . . . . . . . . 22 Gateway . . . . . . . . . . . . . . . . . . . . . . . 22
3.3. Mobility Options and Status Codes . . . . . . . . . . . . 23 3.3. Mobility Options and Status Codes . . . . . . . . . . . . 23
3.3.1. IPv4 Home Address Request Option . . . . . . . . . . . 23 3.3.1. IPv4 Home Address Request Option . . . . . . . . . . . 23
3.3.2. IPv4 Home Address Reply Option . . . . . . . . . . . . 24 3.3.2. IPv4 Home Address Reply Option . . . . . . . . . . . . 24
3.3.3. IPv4 Default-Router Address Option . . . . . . . . . . 25 3.3.3. IPv4 Default-Router Address Option . . . . . . . . . . 25
3.3.4. IPv4 DHCP Support Mode . . . . . . . . . . . . . . . . 26 3.3.4. IPv4 DHCP Support Mode . . . . . . . . . . . . . . . . 26
3.3.5. Status Codes . . . . . . . . . . . . . . . . . . . . . 27 3.3.5. Status Codes . . . . . . . . . . . . . . . . . . . . . 27
3.4. Supporting DHCP-Based Address Configuration . . . . . . . 28 3.4. Supporting DHCP-Based Address Configuration . . . . . . . 28
3.4.1. DHCP Server co-located with the Mobile Access 3.4.1. DHCP Server co-located with the Mobile Access
skipping to change at page 3, line 10 skipping to change at page 3, line 11
4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 37 4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 37
4.1. Local Mobility Anchor Considerations . . . . . . . . . . . 38 4.1. Local Mobility Anchor Considerations . . . . . . . . . . . 38
4.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 38 4.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 38
4.1.2. Extensions to Mobile Node's Policy Profile . . . . . . 39 4.1.2. Extensions to Mobile Node's Policy Profile . . . . . . 39
4.1.3. Signaling Considerations . . . . . . . . . . . . . . . 39 4.1.3. Signaling Considerations . . . . . . . . . . . . . . . 39
4.1.4. Routing Considerations . . . . . . . . . . . . . . . . 42 4.1.4. Routing Considerations . . . . . . . . . . . . . . . . 42
4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 43 4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 43
4.2.1. Extensions to Binding Update List Entry . . . . . . . 43 4.2.1. Extensions to Binding Update List Entry . . . . . . . 43
4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 44 4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 44
4.3. IPsec Considerations . . . . . . . . . . . . . . . . . . . 46 4.3. IPsec Considerations . . . . . . . . . . . . . . . . . . . 46
4.3.1. PBU and PBA . . . . . . . . . . . . . . . . . . . . . 46
4.3.2. Payload Packet . . . . . . . . . . . . . . . . . . . . 50
5. Protocol Configuration Variables . . . . . . . . . . . . . . . 50 5. Protocol Configuration Variables . . . . . . . . . . . . . . . 53
5.1. Local Mobility Anchor - Configuration Variables . . . . . 50 5.1. Local Mobility Anchor - Configuration Variables . . . . . 53
5.2. Mobile Access Gateway - Configuration Variables . . . . . 50 5.2. Mobile Access Gateway - Configuration Variables . . . . . 53
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55
7. Security Considerations . . . . . . . . . . . . . . . . . . . 54 7. Security Considerations . . . . . . . . . . . . . . . . . . . 57
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 55 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 58
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 55 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 58
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58
10.1. Normative References . . . . . . . . . . . . . . . . . . . 56 10.1. Normative References . . . . . . . . . . . . . . . . . . . 59
10.2. Informative References . . . . . . . . . . . . . . . . . . 56 10.2. Informative References . . . . . . . . . . . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60
1. Overview 1. Overview
The transition from IPv4 to IPv6 is a long process and during this The transition from IPv4 to IPv6 is a long process and during this
period of transition, both the protocols will be enabled over the period of transition, both the protocols will be enabled over the
same network infrastructure. Thus, it is reasonable to assume that a same network infrastructure. Thus, it is reasonable to assume that a
mobile node in a Proxy Mobile IPv6 domain may operate in an IPv4-only mobile node in a Proxy Mobile IPv6 domain may operate in an IPv4-only
IPv6-only or in dual-stack mode and additionally the network between IPv6-only or in dual-stack mode and additionally the network between
the mobile access gateway and a local mobility anchor may be an IPv4 the mobile access gateway and a local mobility anchor may be an IPv4
or an IPv6 network. It is also reasonable to expect the same or an IPv6 network. It is also reasonable to expect the same
skipping to change at page 17, line 41 skipping to change at page 17, line 41
Figure 2: Tunneled Packets from LMA to MAG Figure 2: Tunneled Packets from LMA to MAG
Forwarding Packets Sent by the Mobile Node: Forwarding Packets Sent by the Mobile Node:
o All the reverse tunneled packets that the local mobility anchor o All the reverse tunneled packets that the local mobility anchor
receives from the mobile access gateway, after removing the tunnel receives from the mobile access gateway, after removing the tunnel
header MUST be routed to the destination specified in the inner header MUST be routed to the destination specified in the inner
IPv4 packet header. These routed packets will have the source IPv4 packet header. These routed packets will have the source
address field set to the mobile node's IPv4 home address. address field set to the mobile node's IPv4 home address.
3.1.4. ECN & Payload Fragmentation Considerations
The ECN considerations specified in Section 5.6.3 of [RFC-5213] apply
for the IPv4 payload packets as well. The mobility agents at the
tunnel entry and exit points MUST handle ECN information as specified
in that document.
The mobility agents at the tunnel entry and exit points MUST apply
the IP packet fragmentation considerations as specified in section 7
of [RFC-2473] and additionally they MUST apply the considerations
related to tunnel error processing and reporting as specified in
section 8 of [RFC-2473].
3.2. Mobile Access Gateway Considerations 3.2. Mobile Access Gateway Considerations
3.2.1. Extensions to Binding Update List Entry 3.2.1. Extensions to Binding Update List Entry
To support the IPv4 home address mobility feature, the conceptual To support the IPv4 home address mobility feature, the conceptual
Binding Update List entry data structure needs to be extended with Binding Update List entry data structure needs to be extended with
the following additional fields. the following additional fields.
o The IPv4 home address assigned to the mobile node's attached o The IPv4 home address assigned to the mobile node's attached
interface. This IPv4 home address may have been statically interface. This IPv4 home address may have been statically
skipping to change at page 22, line 43 skipping to change at page 23, line 6
o On receiving a packet from a mobile node connected to its access o On receiving a packet from a mobile node connected to its access
link, the packet MUST be forwarded to the local mobility anchor link, the packet MUST be forwarded to the local mobility anchor
through the bi-directional tunnel established with the local through the bi-directional tunnel established with the local
mobility anchor. The encapsulation considerations specified in mobility anchor. The encapsulation considerations specified in
section 3.1.3 MUST be applied. However, before forwarding the section 3.1.3 MUST be applied. However, before forwarding the
packet, the mobile access gateway MUST ensure the source address packet, the mobile access gateway MUST ensure the source address
in the received packet is the address allocated for that mobile in the received packet is the address allocated for that mobile
node and that there is an active binding on the local mobility node and that there is an active binding on the local mobility
anchor for that mobile node. anchor for that mobile node.
o The mobile access gateway MUST use proxy ARP [RFC-925] to reply to o The mobile access gateway MAY use proxy ARP [RFC-925] to reply to
ARP Requests that it receives from the mobile node seeking address ARP Requests that it receives from the mobile node seeking address
resolutions for the destinations on the mobile node's home subnet. resolutions for the destinations on the mobile node's home subnet.
When receiving an ARP Request, the local mobility anchor MUST When receiving an ARP Request, the local mobility anchor can
examine the target IP address of the Request, and if this IP examine the target IP address of the Request, and if this IP
address matches the mobile node's IPv4 home subnet, it MUST address matches the mobile node's IPv4 home subnet, it MAY
transmit a Proxy ARP Reply. transmit a Proxy ARP Reply.
3.3. Mobility Options and Status Codes 3.3. Mobility Options and Status Codes
To support the IPv4 home address mobility feature, this specification To support the IPv4 home address mobility feature, this specification
defines the following new options and Status Codes. defines the following new options and Status Codes.
3.3.1. IPv4 Home Address Request Option 3.3.1. IPv4 Home Address Request Option
A new option, IPv4 Home Address Request Option is defined for use A new option, IPv4 Home Address Request Option is defined for use
skipping to change at page 29, line 8 skipping to change at page 29, line 8
the client and its interface for which the address is assigned. A the client and its interface for which the address is assigned. A
mobile node in a Proxy Mobile IPv6 domain, can attach to the mobile node in a Proxy Mobile IPv6 domain, can attach to the
network through multiple interfaces and can obtain address network through multiple interfaces and can obtain address
configuration for each of its interfaces. Additionally, it may configuration for each of its interfaces. Additionally, it may
perform handoffs between its interfaces. Following are the perform handoffs between its interfaces. Following are the
related considerations with respect to the identification related considerations with respect to the identification
presented to the DHCP server. presented to the DHCP server.
* If the mobile node attaches to the Proxy Mobile IPv6 domain * If the mobile node attaches to the Proxy Mobile IPv6 domain
through multiple interfaces, the DHCP server will uniquely through multiple interfaces, the DHCP server will uniquely
identify each of those interfaces from the client hardware identify each of those interfaces and will perform address
address and will perform address assignment. As the mobile assignment. The DHCP server will identify the client as
specified in [RFC-2131]. If the client identifier is present,
that will be used for identifying the mobile node, otherwise
the client hardware address will be used. Anytime the mobile
node changes its point of attachment in the network and node changes its point of attachment in the network and
performs an handoff to a different mobile access gateway, using performs an handoff to a different mobile access gateway, using
the same interface, the DHCP server will always be able to the same interface, the DHCP server will always be able to
identify the binding using the presented client hardware identify the binding using the presented identifier, the client
address. The client hardware address and client identifier identifier or the hardware address. The client identifier or
will remain as the primary keys for each binding, just as how the hardware address will remain as the primary key for each
they are unique in a Binding Cache entry. binding, just as how they are unique in a Binding Cache entry.
* However, if the mobile node is capable of performing handoff * However, if the mobile node is capable of performing handoff
between interfaces, as per [RFC-5213], the client hardware between interfaces, as per [RFC-5213], the client identifier in
address in such scenarios needs to be an identifier that is not such scenarios needs to be an identifier that is not tied to
tied to any of those interfaces. The identifier must be a any of those interfaces. The identifier must be a stable
stable identifier which remains the same through out the mobile identifier which remains the same through out the mobile node's
node's attachment in that Proxy Mobile IPv6 domain. This attachment in that Proxy Mobile IPv6 domain. This identifier
identifier must remain fixed for a given binding. This must remain fixed for a given binding. This identifier in some
identifier in some implementations can be the identifier implementations can be the identifier associated to a virtual
associated to a virtual interface, that is abstracting the interface, that is abstracting the physical interfaces.
physical interfaces.
o All the DHCP servers co-located with the mobile access gateways in o All the DHCP servers co-located with the mobile access gateways in
a Proxy Mobile IPv6 domain can be configured with the same set of a Proxy Mobile IPv6 domain can be configured with the same set of
DHCP option values (Ex: DNS Server, SIP Server ..etc.) to ensure DHCP option values (Ex: DNS Server, SIP Server ..etc.) to ensure
the mobile node receives the same configuration values on any of the mobile node receives the same configuration values on any of
the access links in that Proxy Mobile IPv6 domain. the access links in that Proxy Mobile IPv6 domain.
3.4.1. DHCP Server co-located with the Mobile Access Gateway 3.4.1. DHCP Server co-located with the Mobile Access Gateway
This section explains the operational sequence of home address This section explains the operational sequence of home address
skipping to change at page 30, line 24 skipping to change at page 30, line 24
* It is possible the MAG may have already completed the Proxy Mobile * It is possible the MAG may have already completed the Proxy Mobile
IPv6 signaling with the LMA for requesting both IPv6 home network IPv6 signaling with the LMA for requesting both IPv6 home network
prefix(es) and IPv4 home address assignment prior to step-1. In prefix(es) and IPv4 home address assignment prior to step-1. In
such event, the Proxy Mobile IPv6 signaling steps (step-2 to such event, the Proxy Mobile IPv6 signaling steps (step-2 to
step-4) above are not relevant. step-4) above are not relevant.
* It is possible the MAG may have initially completed the Proxy * It is possible the MAG may have initially completed the Proxy
Mobile IPv6 signaling prior to Step-1, but only for requesting Mobile IPv6 signaling prior to Step-1, but only for requesting
IPv6 home network prefix(es) and may later request IPv4 home IPv6 home network prefix(es) and may later request IPv4 home
address assignment after detecting the DHCP triggers from the address assignment after detecting the DHCP triggers from the
mobile node as shown above. mobile node as shown above.
* The MAG may choose to ignore the DHCPDISCOVER messages till the
Proxy Mobile IPv6 signaling is successfully completed, or it may
choose to send a delayed response for reducing the additional
delay waiting for a new DHCPDISCOVER message from the mobile node.
Figure 7: Overview of DHCP Server located at Mobile Access Gateway Figure 7: Overview of DHCP Server located at Mobile Access Gateway
Initial IPv4 Home Address Assignment: Initial IPv4 Home Address Assignment:
o For acquiring the mobile node's IPv4 home address from the local o For acquiring the mobile node's IPv4 home address from the local
mobility anchor, the mobile access gateway will initiate Proxy mobility anchor, the mobile access gateway will initiate Proxy
Mobile IPv6 signaling with the local mobility anchor. Mobile IPv6 signaling with the local mobility anchor.
o After the successful completion of the Proxy Mobile IPv6 signaling o After the successful completion of the Proxy Mobile IPv6 signaling
and upon acquiring the mobile node's IPv4 home address from the and upon acquiring the mobile node's IPv4 home address from the
local mobility anchor, the DHCP server on the mobile access local mobility anchor, the DHCP server on the mobile access
gateway will send a DHCPOFFER message [RFC-2131] to the mobile gateway will send a DHCPOFFER message [RFC-2131] to the mobile
node. The offered address will be the mobile node's IPv4 home node. The offered address will be the mobile node's IPv4 home
address, assigned by the local mobility anchor. The DHCPOFFER address, assigned by the local mobility anchor. The DHCPOFFER
message will have the server address field (siaddr) and the message will also have the subnet mask option [RFC-2132] and
default router option set to the mobile node's default router router option [RFC-2132], with the values in those options set to
address. The DHCPOFFER message will be sent to the mobile node the mobile node's IPv4 home subnet mask and default router address
just as specified in [RFC-2131]. respectively. Additionally, the Server Identifier option will be
included and with the value in the option set to the default
router address.
o If the mobile node sends the DHCPREQUEST message, the DHCP server o If the mobile node sends the DHCPREQUEST message, the DHCP server
will send DHCPACK message, as per [RFC-2131]. will send DHCPACK message, as per [RFC-2131].
IPv4 Home Address Renewal with the DHCP server (No Handoff): IPv4 Home Address Renewal with the DHCP server (No Handoff):
o Any time the mobile node goes into the DHCP RENEWING state [RFC- o Any time the mobile node goes into the DHCP RENEWING state [RFC-
2131], it simply unicasts the DHCPREQUEST message including the 2131], it simply unicasts the DHCPREQUEST message including the
assigned IPv4 home address in the 'requested IP address' option. assigned IPv4 home address in the 'requested IP address' option.
The DHCPREQUEST is sent to the address specified in 'server The DHCPREQUEST is sent to the address specified in 'server
skipping to change at page 32, line 31 skipping to change at page 32, line 35
* The Proxy Mobile IPv6 signaling (starting at Step-1) and the * The Proxy Mobile IPv6 signaling (starting at Step-1) and the
DHCP address configuration (starting at Step-4) may start in any DHCP address configuration (starting at Step-4) may start in any
order. However, the DHCPOFFER (Step-5) and the immediate steps order. However, the DHCPOFFER (Step-5) and the immediate steps
following it will occur in the specified order and only after the following it will occur in the specified order and only after the
Tunnel/Route Setup (Step-3). Tunnel/Route Setup (Step-3).
* It is possible the MAG may have initially completed the Proxy * It is possible the MAG may have initially completed the Proxy
Mobile IPv6 signaling with the LMA only for requesting IPv6 home Mobile IPv6 signaling with the LMA only for requesting IPv6 home
network prefix(es) and may later request IPv4 home address network prefix(es) and may later request IPv4 home address
assignment after detecting the DHCP triggers from the mobile node assignment after detecting the DHCP triggers from the mobile node
(after Step-4). (after Step-4).
* The MAG may choose to ignore the DHCPDISCOVER messages till the
Proxy Mobile IPv6 signaling is successfully completed, or it may
choose to send a delayed response for reducing the additional
delay waiting for a new DHCPDISCOVER message from the mobile node.
Figure 9: Overview of the DHCP relay located at mobile access gateway Figure 9: Overview of the DHCP relay located at mobile access gateway
Initial IPv4 Home Address Assignment: Initial IPv4 Home Address Assignment:
o For acquiring the mobile node's IPv4 home address from the local o For acquiring the mobile node's IPv4 home address from the local
mobility anchor, the mobile access gateway will initiate Proxy mobility anchor, the mobile access gateway will initiate Proxy
Mobile IPv6 signaling with the local mobility anchor. Mobile IPv6 signaling with the local mobility anchor.
o After the successful completion of the Proxy Mobile IPv6 signaling o After the successful completion of the Proxy Mobile IPv6 signaling
skipping to change at page 35, line 13 skipping to change at page 35, line 21
NOT enable IPv4 home address mobility support for the mobile node NOT enable IPv4 home address mobility support for the mobile node
on that access link. on that access link.
o The trigger for initiating Proxy Mobile IPv6 signaling can also be o The trigger for initiating Proxy Mobile IPv6 signaling can also be
delivered to the mobile access gateway as part of a context delivered to the mobile access gateway as part of a context
transfer from the previous mobile access gateway, or delivered transfer from the previous mobile access gateway, or delivered
from the other network elements in the radio network, the details from the other network elements in the radio network, the details
of which are outside the scope of this document. of which are outside the scope of this document.
o The DHCPOFFER message [RFC-2131] sent to the mobile node MUST o The DHCPOFFER message [RFC-2131] sent to the mobile node MUST
include the Subnet Mask option [RFC-2132] and the Router option
[RFC-2132]. The values in the Subnet Mask option and Router
option MUST be set to the mobile node's IPv4 home subnet mask and
its default router address respectively.
o The DHCPOFFER message [RFC-2131] sent to the mobile node MUST
include the Interface MTU option [RFC-2132]. The DHCP servers in include the Interface MTU option [RFC-2132]. The DHCP servers in
the Proxy Mobile IPv6 domain MUST be configured to include the the Proxy Mobile IPv6 domain MUST be configured to include the
Interface MTU option. The MTU value SHOULD reflect the tunnel MTU Interface MTU option. The MTU value SHOULD reflect the tunnel MTU
for the bi-directional tunnel between the mobile access gateway for the bi-directional tunnel between the mobile access gateway
and the local mobility anchor. and the local mobility anchor.
o The DHCP lease length allocated to the mobile node's IPv4 home
address may be different from the binding lifetime at the local
mobility anchor for that mobile node's session. It is not
possible to keep these lifetimes synchronized and so its not
required that the configured lifetimes should be kept same in both
DHCP and Proxy Mobile IPv6.
o When the mobile node performs an handoff from one mobile access o When the mobile node performs an handoff from one mobile access
gateway to another, the mobile access gateway on the new link will gateway to another, the mobile access gateway on the new link will
initiate the Proxy Mobile IPv6 signaling with the local mobility initiate the Proxy Mobile IPv6 signaling with the local mobility
anchor. On completing the Proxy Mobile IPv6 signaling, the mobile anchor. On completing the Proxy Mobile IPv6 signaling, the mobile
access gateway has the proper IPv4 address state that the local access gateway has the proper IPv4 address state that the local
mobility anchor has allocated for the mobile node and which can be mobility anchor has allocated for the mobile node and which can be
used for supporting DHCP based address configuration on that link. used for supporting DHCP based address configuration on that link.
o Any time the mobile node detects a link change event due to o Any time the mobile node detects a link change event due to
handoff, or due to other reasons such as re-establishment of the handoff, or due to other reasons such as re-establishment of the
skipping to change at page 35, line 45 skipping to change at page 36, line 18
access links in that Proxy Mobile IPv6 domain, as the mobile access links in that Proxy Mobile IPv6 domain, as the mobile
access gateway configures a fixed link-layer address on all the access gateway configures a fixed link-layer address on all the
access links, as per the base Proxy Mobile IPv6 specification access links, as per the base Proxy Mobile IPv6 specification
[RFC-5213]. The mobile node will not perform any DHCP [RFC-5213]. The mobile node will not perform any DHCP
operation specifically due to this event. operation specifically due to this event.
* If the mobile node is not DNAv4 [RFC-4436] capable, after * If the mobile node is not DNAv4 [RFC-4436] capable, after
receiving the link change event it will enter INIT-REBOOT state receiving the link change event it will enter INIT-REBOOT state
[RFC-2131] and will send a DHCPREQUEST message as specified in [RFC-2131] and will send a DHCPREQUEST message as specified in
Section 3.7 of [RFC-2131]. The mobile node will obtain the Section 3.7 of [RFC-2131]. The mobile node will obtain the
same address configuration as before, as the link change will same address configuration as before, as the link change does
not be transparent to the mobile node in that Proxy Mobile IPv6 not result in any change at the network layer.
domain.
o The mobile node may release its IPv4 home address at any time by o The mobile node may release its IPv4 home address at any time by
sending the DHCPRELEASE message [RFC-2131]. When the mobile sending the DHCPRELEASE message [RFC-2131]. When the mobile
access gateway detects the DHCPRELEASE message sent by the mobile access gateway detects the DHCPRELEASE message sent by the mobile
node, it should consider this as a trigger for de-registering the node, it should consider this as a trigger for de-registering the
mobile node's IPv4 home address. It will apply the considerations mobile node's IPv4 home address. It will apply the considerations
specified in section 3.2.3.3 for performing the de-registration specified in section 3.2.3.3 for performing the de-registration
procedure. However, this operation MUST NOT release any IPv6 home procedure. However, this operation MUST NOT release any IPv6 home
network prefix(es) assigned to the mobile node. network prefix(es) assigned to the mobile node.
skipping to change at page 38, line 36 skipping to change at page 38, line 36
node's IPv4 and IPv6 traffic. The following are the outer headers node's IPv4 and IPv6 traffic. The following are the outer headers
based on the negotiated encapsulation mode. based on the negotiated encapsulation mode.
* IPv4 (IPv4 or IPv6 Payload packet carried in an IPv4 packet). * IPv4 (IPv4 or IPv6 Payload packet carried in an IPv4 packet).
If payload protection using IPsec is enabled for the tunneled If payload protection using IPsec is enabled for the tunneled
traffic, the ESP header follows the outer tunnel header. traffic, the ESP header follows the outer tunnel header.
* IPv4-UDP (Payload packet carried in an IPv4 packet with UDP * IPv4-UDP (Payload packet carried in an IPv4 packet with UDP
header). If payload protection using IPsec is enabled for the header). If payload protection using IPsec is enabled for the
tunneled traffic, the ESP header follows the outer tunnel tunneled traffic, the ESP header follows the outer tunnel
header, as specified in [RFC-3948]. header, as explained in Section 4.3.
* IPv4-UDP-TLV (Payload packet carried in an IPv4 packet with UDP * IPv4-UDP-TLV (Payload packet carried in an IPv4 packet with UDP
and TLV header). Refer to [ID-GREKEY-NEGO]. If payload and TLV header). Refer to [ID-GREKEY-NEGO]. If payload
protection using IPsec is enabled for the tunneled traffic, the protection using IPsec is enabled for the tunneled traffic, the
ESP header follows the outer tunnel header. ESP header follows the outer tunnel header, as explained in
Section 4.3.
4.1. Local Mobility Anchor Considerations 4.1. Local Mobility Anchor Considerations
4.1.1. Extensions to Binding Cache Entry 4.1.1. Extensions to Binding Cache Entry
To support this feature, the conceptual Binding Cache entry data To support this feature, the conceptual Binding Cache entry data
structure maintained by the local mobility anchor [RFC-5213] MUST be structure maintained by the local mobility anchor [RFC-5213] MUST be
extended with the following additional parameters. It is to be noted extended with the following additional parameters. It is to be noted
that all of these parameters are specified in [RFC-5555] and also that all of these parameters are specified in [RFC-5555] and also
required here in the present usage context, and are presented here required here in the present usage context, and are presented here
skipping to change at page 43, line 25 skipping to change at page 43, line 25
o Forwarding Packets Sent by the Mobile Node: o Forwarding Packets Sent by the Mobile Node:
* All the reverse tunneled packets (IPv4 and IPv6) that the local * All the reverse tunneled packets (IPv4 and IPv6) that the local
mobility anchor receives from the mobile access gateway, after mobility anchor receives from the mobile access gateway, after
removing the tunnel header (i.e., the outer IPv4 header along removing the tunnel header (i.e., the outer IPv4 header along
with the UDP and TLV header, if negotiated) MUST be routed to with the UDP and TLV header, if negotiated) MUST be routed to
the destination specified in the inner packet header. These the destination specified in the inner packet header. These
routed packets will have the source address field set to the routed packets will have the source address field set to the
mobile node's home address. mobile node's home address.
4.1.4.2. ECN Considerations 4.1.4.2. ECN & Payload Fragmentation Considerations
The ECN considerations specified in Section 5.6.3 of [RFC-5213] apply The ECN considerations specified in Section 5.6.3 of [RFC-5213] apply
for the IPv4 transport tunnels as well. The mobility agents at the for the IPv4 transport tunnels as well. The mobility agents at the
tunnel entry and exit points MUST handle ECN information as specified tunnel entry and exit points MUST handle ECN information as specified
in that document. in that document.
The mobility agents at the tunnel entry and exit points MUST apply
the IP packet fragmentation considerations as specified in [RFC-
4213]. Additionally they MUST also apply the considerations related
to tunnel error processing and reporting as specified in the same
specification.
4.1.4.3. Bi-Directional Tunnel Management 4.1.4.3. Bi-Directional Tunnel Management
The Tunnel Management considerations specified in section 5.6.1 of The Tunnel Management considerations specified in section 5.6.1 of
[RFC-5213] apply for the IPv4 transport tunnels as well, with just [RFC-5213] apply for the IPv4 transport tunnels as well, with just
one difference that the encapsulation mode is different. one difference that the encapsulation mode is different.
4.2. Mobile Access Gateway Considerations 4.2. Mobile Access Gateway Considerations
4.2.1. Extensions to Binding Update List Entry 4.2.1. Extensions to Binding Update List Entry
skipping to change at page 46, line 24 skipping to change at page 46, line 26
use of EnableMAGLocalRouting flag. use of EnableMAGLocalRouting flag.
IPv4 Header (src= IPv4-Proxy-CoA, dst= IPv4-LMAA)] /* Tunnel Header */ IPv4 Header (src= IPv4-Proxy-CoA, dst= IPv4-LMAA)] /* Tunnel Header */
[UDP Header (src port=DSMIPv6, dst port=Z] /* If UDP encap nego */ [UDP Header (src port=DSMIPv6, dst port=Z] /* If UDP encap nego */
[TLV Header] /* If TLV negotiated */ [TLV Header] /* If TLV negotiated */
/* IPv6 or IPv4 Payload Packet */ /* IPv6 or IPv4 Payload Packet */
IPv6 header (src= CN, dst= MN-HOA) IPv6 header (src= CN, dst= MN-HOA)
OR OR
IPv4 header (src= CN, dst= IPv4 MN-HoA) IPv4 header (src= CN, dst= IPv4 MN-HoA)
Figure 14: Tunneled IPv4 Packet from LMA to MAG Figure 14
o Forwarding Packets received from the bi-directional tunnel: o Forwarding Packets received from the bi-directional tunnel:
o On receiving a packet from the bi-directional tunnel established o On receiving a packet from the bi-directional tunnel established
with the mobile node's local mobility anchor, the mobile access with the mobile node's local mobility anchor, the mobile access
gateway MUST remove the outer header before forwarding the packet gateway MUST remove the outer header before forwarding the packet
to the mobile node. to the mobile node.
4.3. IPsec Considerations 4.3. IPsec Considerations
4.3.1. PBU and PBA
The following section describes how IPsec is used for protecting the The following section describes how IPsec is used for protecting the
signaling messages between the local mobility anchor and mobile signaling messages and data packets between the local mobility anchor
access gateway when using IPv4 transport. and mobile access gateway when using IPv4 transport.
The following are the SPD example entries to protect PBU and PBA on The following are the SPD example entries to protect PBU and PBA on
the local mobility anchor and mobile access gateway. the local mobility anchor and mobile access gateway.
MAG SPD-S: MAG SPD-S:
- IF local_address = Proxy-CoA_1 & - IF local_address = Proxy-CoA_1 &
remote_address = LMAA_1 & proto = MH & remote_address = LMAA_1 & proto = MH &
local_mh_type = PBU & remote_mh_type = PBAck local_mh_type = PBU & remote_mh_type = PBAck
Then use SA ESP transport mode Then use SA ESP transport mode
LMA SPD-S: LMA SPD-S:
- IF local_address = LMAA_1 & - IF local_address = LMAA_1 &
remote_address = Proxy-CoA_1 & proto = MH & remote_address = Proxy-CoA_1 & proto = MH &
local_mh_type = PBAck & remote_mh_type = PBU local_mh_type = PBAck & remote_mh_type = PBU
Then use SA ESP transport mode Then use SA ESP transport mode
Figure 15 and Figure 16 show how PBU and PBA are sent and processed Figure 15 and Figure 16 show how PBU and PBA are sent and processed
at either the local mobility anchor or the mobile access gateway. at the local mobility anchor and at the mobile access gateway. IPsec
IPsec ESP is always applied before PBU and PBA are encapsulated in ESP is always applied before the PBU or the PBA is encapsulated in
the outer IPv4 header. the outer IPv4 header.
| PBU on wire : PBU internal processing | PBU on wire : PBU internal processing
\|/ \:/ \|/ \:/
MAG's PMIP Module
:
: IPv6 header (src=Proxy-CoA, dst=LMAA)
: Mobility header
: PBU (p flag)
: Home Network Prefix option
: IPv4 Home Address Request option
: IPv4 Care-of Address option
:
\:/
MAG's IPsec module
:
: IPv6 header (src=Proxy-CoA, dst=LMAA)
: ESP header in transport mode
: Mobility header
: PBU (p flag)
: Home Network Prefix option
: IPv4 Home Address Request option
: IPv4 Care-of Address option
:
: * After adding the ESP header, the PBU is returned to the PMIP
: module and is encapsulated into the UDP and IPv4 headers.
: This requires a Proxy Mobile IPv6 specific IPsec implementation,
: which knows that the packet needs to be passed back to the PMIP
: module, instead of sending it out via the normal forwarding
\:/
MAG MAG
| IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) | IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)
| UDP header (sport=Z, dport=DSMIPv6) | UDP header (sport=Z, dport=DSMIPv6)
| IPv6 header (src=Proxy-CoA, dst=LMAA) | IPv6 header (src=Proxy-CoA, dst=LMAA)
| ESP header in transport mode | ESP header in transport mode
| Mobility header | Mobility header
| PBU (p flag) | PBU (p flag)
| Home Network Prefix option | Home Network Prefix option
| IPv4 Home Address Request option | IPv4 Home Address Request option
| IPv4 Care-of Address option | IPv4 Care-of Address option
\|/ \|/
LMA (received at DSMIPv6 port) LMA (received at DSMIPv6 port)
:
: IPv6 header (src=Proxy-CoA, dst=LMAA) : IPv6 header (src=Proxy-CoA, dst=LMAA)
: ESP header in transport mode : ESP header in transport mode
: Mobility header : Mobility header
: PBU (p flag) : PBU (p flag)
: Home Network Prefix option : Home Network Prefix option
: IPv4 Home Address Request option : IPv4 Home Address Request option
: IPv4 Care-of Address option : IPv4 Care-of Address option
: :
: *In addition, IPv4-Proxy-CoA and the sport (Z) need to : *In addition, IPv4-Proxy-CoA and the sport (Z) needs to
: be passed with the packet to ensure correct processing. : be passed along with the packet to ensure correct processing.
\:/ \:/
LMA's IPsec module LMA's IPsec module
: :
: IPv6 header (src=Proxy-CoA, dst=LMAA) : IPv6 header (src=Proxy-CoA, dst=LMAA)
: Mobility header : Mobility header
: PBU (p flag) : PBU (p flag)
: Home Network Prefix option : Home Network Prefix option
: IPv4 Home Address Request option : IPv4 Home Address Request option
: IPv4 Care-of Address option : IPv4 Care-of Address option
: :
skipping to change at page 49, line 4 skipping to change at page 48, line 43
: Home Network Prefix option : Home Network Prefix option
: IPv4 Home Address Request option : IPv4 Home Address Request option
: IPv4 Care-of Address option : IPv4 Care-of Address option
: :
: *In addition, IPv4-Proxy-CoA and the sport (Z) need to : *In addition, IPv4-Proxy-CoA and the sport (Z) need to
: be passed with the packet to ensure correct processing. : be passed with the packet to ensure correct processing.
\:/ \:/
LMA's PMIP module LMA's PMIP module
Figure 15: Proxy Binding Update Figure 15: Proxy Binding Update
| PBA on wire : PBA internal processing | PBA on wire : PBA internal processing
\|/ \:/ \|/ \:/
LMA's PMIP module
:
: IPv6 header (src=LMAA, dst=Proxy-CoA)
: Mobility header
: PBA (p flag)
: Home Network Prefix option
: IPv4 Home Address Reply option
: IPv4 Care-of Address option
\:/
LMA's IPsec module
:
: IPv6 header (src=LMAA, dst=Proxy-CoA)
: ESP header in transport mode
: Mobility header
: PBA (p flag)
: Home Network Prefix option
: IPv4 Home Address Reply option
: IPv4 Care-of Address option
:
: * After adding the ESP header, the PBA is returned to the PMIP
: module and is encapsulated into the UDP and IPv4 headers.
: This requires a Proxy Mobile IPv6 specific IPsec implementation,
: which knows that the packet needs to be passed back to the PMIP
: module, instead of sending it out via normal forwarding
\:/
LMA LMA
| IPv4 header (src=IPv4-LMAA, dst=IPv4-Proxy-CoA) | IPv4 header (src=IPv4-LMAA, dst=IPv4-Proxy-CoA)
| UDP header (sport=DSMIPv6, dport=Z) | UDP header (sport=DSMIPv6, dport=Z)
| IPv6 header (src=LMAA, dst=Proxy-CoA) | IPv6 header (src=LMAA, dst=Proxy-CoA)
| ESP header in transport mode | ESP header in transport mode
| Mobility header | Mobility header
| PBA (p flag) | PBA (p flag)
| Home Network Prefix option | Home Network Prefix option
| IPv4 Home Address Reply option | IPv4 Home Address Reply option
| IPv4 Care-of Address option | IPv4 Care-of Address option
\|/ \|/
MAG (received at DSMIPv6 listening port) MAG (received at DSMIPv6 listening port)
:
: IPv6 header (src=LMAA, dst=Proxy-CoA) : IPv6 header (src=LMAA, dst=Proxy-CoA)
: ESP header in transport mode : ESP header in transport mode
: Mobility header : Mobility header
: PBA (p flag) : PBA (p flag)
: Home Network Prefix option : Home Network Prefix option
: IPv4 Home Address Reply option : IPv4 Home Address Reply option
: IPv4 Care-of Address option : IPv4 Care-of Address option
: *In addition, IPv4-Proxy-CoA and the sport (Z) need to : *In addition, IPv4-Proxy-CoA and the sport (Z) need to
: be passed with the packet to ensure correct processing. : be passed with the packet to ensure correct processing.
\:/ \:/
skipping to change at page 50, line 5 skipping to change at page 50, line 18
: Home Network Prefix option : Home Network Prefix option
: IPv4 Home Address Reply option : IPv4 Home Address Reply option
: IPv4 Care-of Address option : IPv4 Care-of Address option
: *In addition, IPv4-Proxy-CoA and the sport (Z) need to : *In addition, IPv4-Proxy-CoA and the sport (Z) need to
: be passed with the packet to ensure correct processing. : be passed with the packet to ensure correct processing.
\:/ \:/
MAG's PMIP module MAG's PMIP module
Figure 16: Proxy Binding Acknowledgement Figure 16: Proxy Binding Acknowledgement
4.3.2. Payload Packet
The following are the SPD example entries to protect payload packets
on the local mobility anchor and mobile access gateway. Note that
the example SPDs protect all payload packets sent to and from mobile
nodes. If an operator needs to apply a different security mechanism
per mobile node, they need to create a SPD and a SA entry per mobile
node.
MAG SPD-S:
- IF interface = IPv6 tunnel to LMAA_1 &
local_address != Proxy-CoA_1 &
remote_address != LMAA_1 & proto=any
Then use SA ESP tunnel mode
LMA SPD-S:
- IF interface = IPv6 tunnel to Proxy-CoA_1 &
local_address != LMAA_1 &
remote_address != Proxy-CoA_1 & proto=any
Then use SA ESP tunnel mode
When a payload packet is protected by IPsec, MAG and LMA SHOULD
always use the tunnel IPv6 header to let the payload packet be IPsec
protected in the ESP tunnel mode. If IPsec is not applied to payload
packets, this additional tunnel IPv6 header SHOULD be omitted and an
IPv4 header SHOULD be used to encapsulate the data packet as shown in
Figure 14 .
| Packet on wire : Packet internal processing
\|/ \:/
MN
| IPv4/v6 header (src= MN-HoA, dst= CN)
| Payload
\|/
MAG's PMIP Module
:3
: IPv6 header (src=Proxy-CoA, dst=LMAA)
: IPv4/v6 header (src= MN-HoA, dst= CN)
: Payload
:
\:/
MAG's IPsec module
:
: IPv6 header (src=Proxy-CoA, dst=LMAA)
: ESP header in tunnel mode
: IPv4/v6 header (src= MN-HoA, dst= CN)
: Payload
:
: * After the ESP header installation, the payload packet is returned
: to the PMIP module and is encapsulated for the tunnel between MAG
: and LMA. If necessary, the UDP and TLV headers are added to the
: payload packet.
: This requires a Proxy Mobile IPv6 specific IPsec implementation,
: which knows that the packet needs to be passed back to the PMIP
: module, instead of sending it out via normal forwarding
\:/
MAG
|
| IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)
| UDP header (sport=Z, dport=DSMIPv6) /* If UDP encap nego */
| TLV Header /* If TLV negotiated */
| IPv6 header (src=Proxy-CoA, dst=LMAA)
| ESP header in tunnel mode
: IPv4/v6 header (src= MN-HoA, dst= CN)
| Payload
\|/
LMA (received at DSMIPv6 port)
:
: IPv6 header (src=Proxy-CoA, dst=LMAA)
: ESP header in tunnel mode
: IPv4/v6 header (src= MN-HoA, dst= CN)
: Payload
:
: *In addition, IPv4-Proxy-CoA and the sport (Z) need to
: be passed with the packet to ensure correct processing.
\:/
LMA's IPsec module
:
: IPv6 header (src=Proxy-CoA, dst=LMAA)
: IPv4/v6 header (src= MN-HoA, dst= CN)
: Payload
:
: *In addition, IPv4-Proxy-CoA and the sport (Z) need to
: be passed with the packet to ensure correct processing.
\:/
LMA forwarding engine
Figure 17: IPsec Protected Payload Packet
5. Protocol Configuration Variables 5. Protocol Configuration Variables
5.1. Local Mobility Anchor - Configuration Variables 5.1. Local Mobility Anchor - Configuration Variables
The local mobility anchor MUST allow the following variables to be The local mobility anchor MUST allow the following variables to be
configured by the system management. The configured values for these configured by the system management. The configured values for these
protocol variables MUST survive server reboots and service restarts. protocol variables MUST survive server reboots and service restarts.
AcceptForcedIPv4UDPEncapsulationRequest AcceptForcedIPv4UDPEncapsulationRequest
skipping to change at page 56, line 43 skipping to change at page 59, line 43
[RFC-1332] G. McGregor, "The PPP Internet Protocol Control Protocol [RFC-1332] G. McGregor, "The PPP Internet Protocol Control Protocol
(IPCP)", RFC 1332, May 1992. (IPCP)", RFC 1332, May 1992.
[RFC-1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [RFC-1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC
1918, February 1996. 1918, February 1996.
[RFC-2132] Alexander, S. & Droms, R., "DHCP Options and BOOTP Vendor [RFC-2132] Alexander, S. & Droms, R., "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
[RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
[RFC-3022] Srisuresh, P. and K. Egevang, "Traditional IP Network [RFC-3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, January 2001. Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC-3046] M. Patrick, "DHCP Relay Agent Information Option", January [RFC-3046] M. Patrick, "DHCP Relay Agent Information Option", January
2001. 2001.
[RFC-3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global [RFC-3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
Unicast Address Format", RFC 3587, August 2003. Unicast Address Format", RFC 3587, August 2003.
[RFC-3948] Huttunen, A. et al, "UDP Encapsulation of IPsec ESP [RFC-4213] E. Nordmark and R. Gilligan, "Basic Transition Mechanisms
Packets", RFC 3948, January 2005. for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC-4301] Kent, S. and K. Seo, "Security Architecture for the [RFC-4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC-4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC [RFC-4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005. 4306, December 2005.
[RFC-4436] Aboba, B., Carlson, J. and S.Cheshire, "Detecting Network [RFC-4436] Aboba, B., Carlson, J. and S.Cheshire, "Detecting Network
Attachment in IPv4", RFC 4436, March 2006. Attachment in IPv4", RFC 4436, March 2006.
 End of changes. 43 change blocks. 
54 lines changed or deleted 250 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/