draft-ietf-mip6-nemo-v4traversal-00.txt   draft-ietf-mip6-nemo-v4traversal-01.txt 
MIP6 Working Group Hesham Soliman MIP6 Working Group Hesham Soliman
INTERNET-DRAFT George Tsirtsis INTERNET-DRAFT George Tsirtsis
Expires: April 2006 Flarion Expires: September 2006 Flarion
Vijay Deverapalli Vijay Deverapalli
Nokia Nokia
James Kempf James Kempf
Docomo Labs Docomo Labs
Henrik Levkowetz Henrik Levkowetz Ericsson
Ericsson
Pascal Thubert Pascal Thubert
Cisco Cisco
Ryuji Wakikawa Ryuji Wakikawa
Keio University Keio University
October, 2005 March, 2006
Dual Stack Mobile IPv6 (DSMIPv6) Mobile IPv6 support for dual stack
for Hosts and Routers Hosts and Routers (DSMIPv6)
draft-ietf-mip6-nemo-v4traversal-00.txt draft-ietf-mip6-nemo-v4traversal-01.txt
Status of this memo Status of this memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of 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 other Task Force (IETF), its areas, and its working groups. Note that other
skipping to change at page 2, line 22 skipping to change at page 2, line 22
Table of Contents Table of Contents
1. Introduction.....................................................2 1. Introduction.....................................................2
1.1 Motivation for using Mobile IPv6 only...........................3 1.1 Motivation for using Mobile IPv6 only...........................3
1.2 Scenarios considered by this specification...................4 1.2 Scenarios considered by this specification...................4
2. Solution overview................................................5 2. Solution overview................................................5
2.1. Home Agent Address Discovery...................................5 2.1. Home Agent Address Discovery...................................5
2.2. Mobile Prefix Solicitations and Advertisements..............6 2.2. Mobile Prefix Solicitations and Advertisements..............6
2.3. Binding management.............................................6 2.3. Binding management.............................................6
2.3.1 Foreign network supports IPv6.................................7 2.3.1 Foreign network supports IPv6.................................7
2.3.2 Foreign network supports IPv4 only............................7 2.3.2 Foreign network supports IPv4 only............................8
2.3.2.1 Visited network supports IPv4 only (private addresses)......8 2.3.2.1 Visited network supports IPv4 only (private addresses)......9
2.4. Route optimization.............................................9 2.4. Route optimization.............................................9
2.5. Dynamic IPv4 home address allocation..........................10 2.5. Dynamic IPv4 home address allocation..........................10
3. Extensions and modifications to Mobile IPv6.....................10 3. Extensions and modifications to Mobile IPv6.....................10
3.1. Binding update extensions.....................................10 3.1. Binding update extensions.....................................10
3.1.1 IPv4 home address option.....................................10 3.1.1 IPv4 home address option.....................................10
3.2. Binding acknowledgement extensions............................11 3.2. Binding acknowledgement extensions............................11
3.2.1 IPv4 address acknowledgement option..........................11 3.2.1 IPv4 address acknowledgement option..........................11
3.2.2 The NAT detection option...............................12 3.2.2 The NAT detection option...............................12
4. Protocol operation..............................................12 4. Protocol operation..............................................13
4.1. NAT detection and traversal................................13 4.1. NAT detection and traversal................................13
4.2. Mobile node operation.........................................14 4.2. NAT Keepalives.............................................14
4.3. Home agent operations.........................................16 4.3. Mobile node operation.........................................15
4.4. Correspondent node operations.................................17 4.4. Home agent operations.........................................16
5. Security considerations.........................................17 4.5. Correspondent node operations.................................18
6. Protocol constants..............................................18 5. Security considerations.........................................18
7. Acknowledgements................................................18 6. Protocol constants..............................................19
8. IANA considerations.............................................18 7. Acknowledgements................................................19
9. References......................................................18 8. IANA considerations.............................................19
Authors' Addresses.................................................19 9. References......................................................19
Authors' Addresses.................................................20
1. Introduction 1. Introduction
Mobile IPv6 [MIPv6] and [NEMO] allow mobile nodes to move within the Mobile IPv6 [MIPv6] and [NEMO] allow mobile nodes to move within the
Internet while maintaining reachability and ongoing sessions, using Internet while maintaining reachability and ongoing sessions, using
an IPv6 home address or prefix. However, since IPv6 is not widely an IPv6 home address or prefix. However, since IPv6 is not widely
deployed, it is unlikely that mobile nodes will use IPv6 addresses deployed, it is unlikely that mobile nodes will use IPv6 addresses
only for their connections. It is reasonable to assume that mobile only for their connections. It is reasonable to assume that mobile
nodes will, for a long time, need an IPv4 home address that can be nodes will, for a long time, need an IPv4 home address that can be
used by upper layers. It is also reasonable to assume that mobile used by upper layers. It is also reasonable to assume that mobile
nodes will move to networks that might not support IPv6 and would nodes will move to networks that might not support IPv6 and would
therefore need an IPv4 Care-of Address. The current Mobile IPv6 therefore need the capability to support an IPv4 Care-of Address.
specification and [NEMO] do not allow mobile nodes to use an IPv4
home address or prefix, respectively. Hence, this specification Hence, this specification extends Mobile IPv6 capabilities to allow
extends Mobile IPv6 capabilities to allow dual stack mobile nodes to dual stack mobile nodes to request that their home agent (also dual
request that their home agent (also dual stacked) tunnel IPv4/IPv6 stacked) tunnel IPv4/IPv6 packets addressed to their home addresses,
packets addressed to their home addresses, to their IPv4/IPv6 care-of to their IPv4/IPv6 care-of address(es).
address(es).
Using this specification, mobile nodes would only need Mobile IPv6 Using this specification, mobile nodes would only need Mobile IPv6
and [NEMO] to manage mobility while moving within the Internet. This and [NEMO] to manage mobility while moving within the Internet; hence
specification provides the extensions needed in order to allow Mobile eliminating the need to run two mobility management protocols
IPv6 only to be used by dual sack mobile nodes. simultaneously. This specification provides the extensions needed in
order to allow Mobile IPv6 only to be used by dual sack mobile nodes.
This specification will also consider cases where a mobile node moves This specification will also consider cases where a mobile node moves
into a private IPv4 network and gets configured with a private IPv4 into a private IPv4 network and gets configured with a private IPv4
Care-of Address. In those scenarios, the mobile node needs to be able Care-of Address. In those scenarios, the mobile node needs to be able
to traverse the NAT in order to communicate with the Home Agent. NAT to traverse the IPv4 NAT in order to communicate with the Home Agent.
traversal for Mobile IPv6 is presented in this specification. IPv4 NAT traversal for Mobile IPv6 is presented in this
specification.
In this specification, the term mobile node refers to both a mobile In this specification, the term mobile node refers to both a mobile
host and mobile router unless the discussion is specific to either host and mobile router unless the discussion is specific to either
hosts or routers. Similarly, we use the term home address to reflect hosts or routers. Similarly, we use the term home address to reflect
an address/prefix format. an address/prefix format.
In this specification, extensions are defined for the binding update In this specification, extensions are defined for the binding update
and binding acknowledgement. It should be noted that all these and binding acknowledgement. It should be noted that all these
extensions apply to cases where the mobile node communicates with a extensions apply to cases where the mobile node communicates with a
Mobility Anchor Point (MAP) as defined in [HMIPv6]. The requirements Mobility Anchor Point (MAP) as defined in [HMIPv6]. The requirements
skipping to change at page 3, line 52 skipping to change at page 3, line 54
One of the advantages of the large address space provided by IPv6 is One of the advantages of the large address space provided by IPv6 is
that it allows mobile nodes to obtain a globally unique care-of that it allows mobile nodes to obtain a globally unique care-of
address wherever they are. Hence, there is no need for Network address wherever they are. Hence, there is no need for Network
Address Translator (NAT) traversal techniques designed for Mobile Address Translator (NAT) traversal techniques designed for Mobile
IPv4. This allows Mobile IPv6 to be a significantly simpler and more IPv4. This allows Mobile IPv6 to be a significantly simpler and more
bandwidth efficient mobility management protocol. At the same time, bandwidth efficient mobility management protocol. At the same time,
during the transition towards IPv6, NAT traversal for existing during the transition towards IPv6, NAT traversal for existing
private IPv4 networks needs to be considered. This specification private IPv4 networks needs to be considered. This specification
introduces NAT traversal for this purpose. introduces NAT traversal for this purpose.
All of the above benefits make the case for using Mobile IPv6 only The above benefits make the case for using Mobile IPv6 only for dual
for dual stack mobile nodes in order to allow for a long lasting stack mobile nodes in order to allow for a long lasting mobility
mobility solution and minimize the need to changing the mobility solution and minimize the need to changing the mobility stack due to
stack due to the introduction of IPv6 within a deployed network. the introduction of IPv6 within a deployed network.
1.2 Scenarios considered by this specification 1.2 Scenarios considered by this specification
In [SNRIO] several scenarios that illustrate potential In [SNRIO] several scenarios that illustrate potential
incompatibilities for mobile nodes using Mobile IPv6 were discussed. incompatibilities for mobile nodes using Mobile IPv6 were discussed.
Some of the problems associated with mobility and transition issues Some of the problems associated with mobility and transition issues
were presented in [MIP-PB]. This specification considers a subset of were presented in [MIP-PB]. This specification considers a subset of
the scenarios in [SNRIO], which address all the problems discussed in the scenarios in [SNRIO], which address all the problems discussed in
[MIP-PB]. The scenarios considered in this specification are listed [MIP-PB]. The scenarios considered in this specification are listed
below. below.
skipping to change at page 5, line 43 skipping to change at page 5, line 43
to allow mobile nodes to use Mobile IPv6 only for IP mobility to allow mobile nodes to use Mobile IPv6 only for IP mobility
management. management.
2.1. Home Agent Address Discovery 2.1. Home Agent Address Discovery
Dynamic Home Agent Address Discovery (DHAAD) was defined in [MIPv6] Dynamic Home Agent Address Discovery (DHAAD) was defined in [MIPv6]
to allow mobile nodes to discover their home agents by appending a to allow mobile nodes to discover their home agents by appending a
well-known anycast interface identifier to their home link's prefix. well-known anycast interface identifier to their home link's prefix.
However, this mechanism is based on IPv6-anycast routing. If a mobile However, this mechanism is based on IPv6-anycast routing. If a mobile
node is located in an IPv4-only foreign network, it cannot rely on node is located in an IPv4-only foreign network, it cannot rely on
native IPv6 routing. native IPv6 routing. The preferred solution for discovering the home
agent's IPv4 address is through the Domain Name System (DNS).
The preferred solution for discovering the home agent's IPv4 address For DNS lookup by name, the mobile node should be configured with the
is through the Domain Name System (DNS). For DNS lookup by name, the name of the home agent. When the mobile node needs to discover a
mobile node should be configured with the name of the home agent. home agent, it sends a DNS request with QNAME set to the configured
When the mobile node needs to discover a home agent, it sends a DNS name. An example is "ha1.example.com". If a home agent has an IPv4
request with QNAME set to the configured name. An example is and IPv6 address, the corresponding DNS record should be configured
"ha1.example.com". If a home agent has an IPv4 and IPv6 address, the with both 'AAAA' and 'A' records. Accordingly the DNS reply will
corresponding DNS record should be configured with both 'AAAA' and contain 'AAAA' and 'A' records.
'A' records. Accordingly the DNS reply will contain 'AAAA' and 'A'
records.
For DNS lookup by service, the SRV record defined in [BOOT] is For DNS lookup by service, the SRV record defined in [BOOT] is
reused. For instance, if the service name is "mip6ha" and the reused. For instance, if the service name is "_mip6ha" and the
protocol name is "ipv6" for the SRV record, the mobile node SHOULD protocol name is "_ipv6" for the SRV record, the mobile node SHOULD
send a DNS request with the QNAME set to "mip6ha.ipv6.example.com". send a DNS request with the QNAME set to "mip6ha.ipv6.example.com".
The response should contain the home agent's FQDN(s) and may have the The response should contain the home agent's FQDN(s) and may have the
corresponding 'AAAA' and 'A' records enclosed as well. corresponding 'AAAA' and 'A' records enclosed as well.
If multiple home agents reside on the home link, each configured with If multiple home agents reside on the home link, each configured with
a public IPv4 addresses, then the operation above applies. In case a public IPv4 addresses, then the operation above applies. In case
the home agents are behind a NAT box, there are two options, 1) the home agents are behind a NAT box, there are two options, 1)
configure a public IPv4 address for each home agent on the NAT box, configure a public IPv4 address for each home agent on the NAT box,
2) configure one public address and make the home agents share the 2) configure one public address and make the home agents share the
public address. In either case, the correct DNS entries can be public address. In either case, the correct DNS entries can be
skipping to change at page 6, line 39 skipping to change at page 6, line 39
Solicitation and receive a Mobile Prefix Advertisement containing all Solicitation and receive a Mobile Prefix Advertisement containing all
prefixes advertised on the home link. prefixes advertised on the home link.
A dual stack mobile node MAY send a Mobile Prefix Solicitation A dual stack mobile node MAY send a Mobile Prefix Solicitation
message encapsulated in IPv4 (i.e. IPv6 in IPv4) in the case where message encapsulated in IPv4 (i.e. IPv6 in IPv4) in the case where
the mobile node has no access to IPv6 within the local network. the mobile node has no access to IPv6 within the local network.
Securing such messages would require the mobile node to have security Securing such messages would require the mobile node to have security
association with the home agent, using IPsec (AH or ESP) and based on association with the home agent, using IPsec (AH or ESP) and based on
the mobile node's IPv4 care-of address as described in [MIPv6]. Since the mobile node's IPv4 care-of address as described in [MIPv6]. Since
the mobile node needs to encapsulate all IPv6 traffic sent to the the mobile node needs to encapsulate all IPv6 traffic sent to the
home agent into IPv4, while located in an IPv4-only visited network, home agent into IPv4 while located in an IPv4-only visited network,
such SA would affect all packets if the selectors were based on the such SA would affect all packets if the selectors were based on the
information in the outer header. That is, the SA selectors being the information in the outer header. That is, the SA selectors being the
protocol number (protocol is always IP in IP), as well as, source and protocol number (protocol is always IP in IP), as well as, source and
destination addresses are all common to all packets. If this effect destination addresses are all common to all packets. If this effect
is not desired, the mobile node can base the SA on the information in is not desired, the mobile node can base the SA on the information in
the inner header (i.e. using the home agent's IPv6 address, the the inner header (i.e. using the home agent's IPv6 address, the
mobile node's home address and the ICMP protocol number). Such mobile node's home address and the ICMP protocol number). Such
security association would use transport mode ESP protection. security association would use transport mode ESP protection.
2.3. Binding management 2.3. Binding management
skipping to change at page 7, line 53 skipping to change at page 7, line 53
the IPv4 home address. If this option is not included in the binding the IPv4 home address. If this option is not included in the binding
acknowledgement and the IPv4 home address option was included in the acknowledgement and the IPv4 home address option was included in the
binding update, the mobile node MUST assume that the home agent does binding update, the mobile node MUST assume that the home agent does
not support the IPv4 home address option and therefore SHOULD NOT not support the IPv4 home address option and therefore SHOULD NOT
include the option in future binding updates to that home agent include the option in future binding updates to that home agent
address. address.
The routing header in the binding update MUST include the mobile The routing header in the binding update MUST include the mobile
node's IPv6 home address as specified in [MIPv6]. node's IPv6 home address as specified in [MIPv6].
When a mobile node acquires both IPv4 and IPv6 care-of addresses at
foreign network, it SHOULD prioritize IPv6 care-of address for MIP6
binding registration. The mobile node MUST NOT register both IPv4 and
IPv6 care-of addresses to its home agent.
2.3.2 Foreign network supports IPv4 only 2.3.2 Foreign network supports IPv4 only
If the mobile node is in a foreign network that only supports IPv4, If the mobile node is in a foreign network that only supports IPv4,
it needs to first detect whether a NAT is in its communication path it needs to detect whether a NAT is in its communication path to the
to the home agent. This is done using the NAT detection mechanism home agent. This is done while exchanging the binding update and
presented later in this document. If no NAT is detected between the acknowledgement messages as shown later in this document. If no NAT
mobile node and the home agent, the mobile node assumes that it is in is detected between the mobile node and the home agent, the mobile
a foreign network that supports IPv4 public addresses. Otherwise, the node assumes that it is in a foreign network that supports IPv4
mobile node assumes that private addresses are used in the foreign public addresses. Otherwise, the mobile node assumes that private
network. Note that this assumption is only valid for the purposes of addresses are used in the foreign network. Note that this assumption
the signaling presented in this specification. A mobile node SHOULD is only valid for the purposes of the signaling presented in this
NOT assume that its IPv4 address is globally unique if a NAT device specification. A mobile node SHOULD NOT assume that its IPv4 address
was not detected. The operations of both cases are discussed below. is globally unique if a NAT device was not detected. The operations
of both cases are discussed below.
2.3.2.2 Foreign network supports IPv4 only (public addresses) 2.3.2.2 Foreign network supports IPv4 only (public addresses)
In this scenario the mobile node will need to tunnel IPv6 packets In this scenario the mobile node will need to tunnel IPv6 packets
containing the binding update to the home agent's IPv4 address. The containing the binding update to the home agent's IPv4 address. The
mobile node uses the IPv4 address it gets from the foreign network as mobile node uses the IPv4 address it gets from the foreign network as
a source address in the outer header. The binding update will contain a source address in the outer header. The binding update will contain
the mobile node's IPv6 home address in the home address option. the mobile node's IPv6 home address in the home address option.
However, since the care-of address in this scenario is the mobile However, since the care-of address in this scenario is the mobile
node's IPv4 address, the mobile node MUST include its IPv4 care-of node's IPv4 address, the mobile node MUST include its IPv4 care-of
skipping to change at page 9, line 22 skipping to change at page 9, line 29
After accepting the binding update, the home agent MUST create a new After accepting the binding update, the home agent MUST create a new
binding cache entry for the mobile node's IPv6 home address. If an binding cache entry for the mobile node's IPv6 home address. If an
IPv4 home address option were included, the home agent MUST create IPv4 home address option were included, the home agent MUST create
another entry for that address. All entries MUST point to the mobile another entry for that address. All entries MUST point to the mobile
node's IPv4 care-of address included in the source address of the node's IPv4 care-of address included in the source address of the
IPv6 packet and represented as an IPv4-mapped IPv6 address. In IPv6 packet and represented as an IPv4-mapped IPv6 address. In
addition, the tunnel used MUST indicate UDP encapsulation for NAT addition, the tunnel used MUST indicate UDP encapsulation for NAT
traversal. Hence, all packets addressed to the mobile node's home traversal. Hence, all packets addressed to the mobile node's home
address(es) (IPv4 or IPv6) will be encapsulated in UDP then address(es) (IPv4 or IPv6) will be encapsulated in UDP then
encapsulated an IPv4 header that includes the home agent's IPv4 encapsulated in an IPv4 header that includes the home agent's IPv4
address in the source address field and the mobile node's IPv4 care- address in the source address field and the mobile node's IPv4 care-
of address in the destination address field. of address in the destination address field.
After accepting the binding updates and creating the corresponding After accepting the binding updates and creating the corresponding
entries, the home agent MUST send a binding acknowledgement as entries, the home agent MUST send a binding acknowledgement as
specified in [MIPv6]. In addition, if the binding update included an specified in [MIPv6]. In addition, if the binding update included an
IPv4 home address option, the binding acknowledgement MUST include IPv4 home address option, the binding acknowledgement MUST include
the IPv4 address acknowledgment option as described later in this the IPv4 address acknowledgment option as described later in this
specification. The binding update is encapsulated in UDP then IPv4 specification. The binding acknowledgement is encapsulated in UDP
with the home agent's IPv4 address in the source address field and then IPv4 with the home agent's IPv4 address in the source address
the mobile node's IPv4 care-of address in the destination field. The field and the mobile node's IPv4 care-of address in the destination
inner IPv6 packet will contain the home agent's IPv6 address as a field. The inner IPv6 packet will contain the home agent's IPv6
source address and the mobile node's IPv4 care-of address in the address as a source address and the mobile node's IPv4 care-of
destination address field. The latter is represented as an IPv4- address in the destination address field. The latter is represented
mapped IPv6 address. as an IPv4-mapped IPv6 address.
The mobile node needs to maintain the NAT bindings for its current The mobile node needs to maintain the NAT bindings for its current
IPv4 care-of address. This is done through sending the binding update IPv4 care-of address. This is done through sending the binding update
regularly to the home agent. regularly to the home agent.
2.4. Route optimization 2.4. Route optimization
Route optimization, as specified in [MIPv6] will operate in an Route optimization, as specified in [MIPv6] will operate in an
identical manner for dual stack mobile nodes when they are located in identical manner for dual stack mobile nodes when they are located in
a visited network that provides IPv6 addresses to the mobile node. a visited network that provides IPv6 addresses to the mobile node.
skipping to change at page 10, line 46 skipping to change at page 11, line 4
| IPv4 home address | | IPv4 home address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type TBD Type TBD
Length 1 Length 1
Pref The length of the prefix associated with the Pref The length of the prefix associated with the
home address. If only a single address is home address. If only a single address is
needed/allowed, this field MUST be set to 32. needed/allowed, this field MUST be set to 32.
Otherwise, this field includes the IPv4 prefix Otherwise, this field includes the IPv4 prefix
Length. Length.
Res This field is reserved for future use. It MUST Res This field is reserved for future use. It MUST
be set to zero by the sender and ignored by the be set to zero by the sender and ignored by the
receiver. receiver.
IPv4 home address The mobile node's IPv4 home address that should IPv4 home address The mobile node's IPv4 home address that should
be defended by the home agent. This field could be defended by the home agent. This field could
contain any unicast IPv4 address (public or contain any unicast IPv4 address (public or
private) that was assigned to the mobile node. private) that was assigned to the mobile node.
The value 0.0.0.0 is used to request an IPv4 The value 0.0.0.0 is used to request an IPv4
home address from the home agent. A prefix can home address from the home agent. A prefix can
be requested if the unspecified address is used be requested by setting the address to 0.0.0.0
and the requested prefix length is included in and setting the Pref field to the requested
the Pref field. prefix length instead of the value 32.
3.2. Binding acknowledgement extensions 3.2. Binding acknowledgement extensions
3.2.1 IPv4 address acknowledgement option 3.2.1 IPv4 address acknowledgement option
This option is included in the Mobility Header including the binding This option is included in the Mobility Header including the binding
acknowledgement message sent from the home agent or Mobility Anchor acknowledgement message sent from the home agent or Mobility Anchor
Point to the mobile node. This option indicates whether a binding Point to the mobile node. This option indicates whether a binding
cache entry was created for the mobile node's IPv4 address. cache entry was created for the mobile node's IPv4 address.
Additionally, this option can include an IPv4 home address in case Additionally, this option can include an IPv4 home address in case
skipping to change at page 11, line 47 skipping to change at page 12, line 4
address binding. Values from 0 to 127 indicate address binding. Values from 0 to 127 indicate
success. Higher values indicate failure. The success. Higher values indicate failure. The
following values are reserved: following values are reserved:
0 Success 0 Success
128 Failure, reason unspecified 128 Failure, reason unspecified
129 Administratively prohibited 129 Administratively prohibited
130 Incorrect IPv4 home address 130 Incorrect IPv4 home address
131 Invalid IPv4 address 131 Invalid IPv4 address
132 Dynamic IPv4 home address 132 Dynamic IPv4 home address
assignment not available assignment not available
Pref The prefix length of the address allocated. This Pref The prefix length of the address allocated. This
field is only valid in case of success and MUST field is only valid in case of success and MUST
be ignored in case of failure. This field be set to zero and ignored in case of failure.
overrides what the mobile node requested (i.e. This field overrides what the mobile node
if not equal to the requested length). requested (if not equal to the requested
length).
Res This field is reserved for future use. It MUST Res This field is reserved for future use. It MUST
be set to zero by the sender and ignored by the be set to zero by the sender and ignored by the
receiver. receiver.
IPv4 home address The IPv4 home address that the home agent will IPv4 home address The IPv4 home address that the home agent will
use in the binding cache entry. This could be a use in the binding cache entry. This could be a
public or private address. This field MUST public or private address. This field MUST
contain the mobile node's IPv4 address. contain the mobile node's IPv4 home address.
If the address were dynamically allocated the If the address were dynamically allocated the
home agent will add the address to inform the home agent will add the address to inform the
mobile node. Otherwise, if the address were mobile node. Otherwise, if the address were
statically allocated to the mobile node, the statically allocated to the mobile node, the
home agent will copy it from the binding update home agent will copy it from the binding update
message. message.
3.2.2 The NAT detection option 3.2.2 The NAT detection option
This option is sent from the home agent to the mobile node to This option is sent from the home agent to the mobile node to
indicate whether a NAT was in the path. This option MAY also include indicate whether a NAT was in the path. This option MAY also include
a suggested NAT binding refresh time for the mobile node. a suggested NAT binding refresh time for the mobile node.
0 1 2 3 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | | Type | Length |F| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Refresh time | | Refresh time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type TBD Type TBD
Length 1 Length 1
F This flag indicates to the mobile node that UDP
encapsulation is required. When set, this flag
indicates that the mobile node MUST use UDP
encapsulation even if a NAT is not located
between the mobile node and home agent.
Reserved This field is reserved for future use. It MUST Reserved This field is reserved for future use. It MUST
be set to zero by the sender and ignored by the be set to zero by the sender and ignored by the
receiver. receiver.
Refresh time A suggested time (in seconds) for the mobile Refresh time A suggested time (in seconds) for the mobile
node to refresh the NAT binding. If set to zero, node to refresh the NAT binding. If set to zero,
be ignored. it is ignored. If this field is set to the all
1s it means that keepalives are not needed, i.e.
no NAT was detected.
4. Protocol operation 4. Protocol operation
This section presents the protocol operation and processing for the This section presents the protocol operation and processing for the
messages presented above. In addition, this section introduces the messages presented above. In addition, this section introduces the
NAT detection and traversal mechanism used by this specification. NAT detection and traversal mechanism used by this specification.
4.1. NAT detection and traversal 4.1. NAT detection and traversal
NAT detection is done when the initial binding update message is sent NAT detection is done when the initial binding update message is sent
from the mobile node to the home agent. When located in an IPv4-only from the mobile node to the home agent. When located in an IPv4-only
foreign link, the mobile node sends the binding update message is foreign link, the mobile node sends the binding update message
sent encapsulated in UDP and IPv4. The source address of the IPv6 encapsulated in UDP and IPv4. The source address of the IPv6 packet
packet is the mobile node's IPv4 care-of address represented in IPv4- is the mobile node's IPv4 care-of address represented in IPv4-mapped
mapped IPv6 format. The destination address is the IPv6 address of IPv6 format. The destination address is the IPv6 address of the home
the home agent. The IPv4 header contains the IPv4 care-of address in agent. The IPv4 header contains the IPv4 care-of address in the
the source address field and the IPv4 address of the home agent in source address field and the IPv4 address of the home agent in the
the destination address field. destination address field.
When the home agent receives the encapsulated binding update it When the home agent receives the encapsulated binding update it
compares the IPv4 address in the source address field in the IPv4 compares the IPv4 address of the source address field in the IPv4
header with the IPv4 address in the source address of the IPv6 header with the IPv4 address in the source address of the IPv6
header. If the two addresses match, no NAT device was in the path. header. If the two addresses match, no NAT device was in the path.
Otherwise, a NAT device was in the path and the NAT detection option Otherwise, a NAT device was in the path and the NAT detection option
is included in the binding acknowledgement. The binding is included in the binding acknowledgement. The binding
acknowledgement, and all future packets are then encapsulated in UDP acknowledgement, and all future packets, are then encapsulated in UDP
and IPv4. The source address in the IPv4 header is the IPv4 address and IPv4. The source address in the IPv4 header is the IPv4 address
of the home agent. The destination address is the IPv4 address of the home agent. The destination address is the IPv4 address
received in the IPv4 header encapsulating the binding update (this received in the IPv4 header encapsulating the binding update (this
address will be different from the IPv4 care-of address if a NAT were address will be different from the IPv4 care-of address when a NAT is
present in the path). in the path).
Upon receiving the binding acknowledgement with the NAT detection Upon receiving the binding acknowledgement with the NAT detection
option, the mobile node sets the tunnel to the home agent to UDP option, the mobile node sets the tunnel to the home agent to UDP
encapsulation. Hence, all future packets to the home agent are encapsulation. Hence, all future packets to the home agent are
tunneled in UDP and IPv4. For all tunneled IPv6 packets, the source tunneled in UDP and IPv4. For all tunneled IPv6 packets, the source
address in the IPv6 header is the mobile node's IPv6 home address and address in the IPv6 header is the mobile node's IPv6 home address and
the destination address is the correspondent node's IPv6 address. All the destination address is the correspondent node's IPv6 address. All
tunneled IPv4 packets will contain the mobile node's IPv4 address in tunneled IPv4 packets will contain the mobile node's IPv4 home
the source address field of the inner IPv4 packet and the address in the source address field of the inner IPv4 packet and the
correspondent node's IPv4 address in the destination address field. correspondent node's IPv4 address in the destination address field.
The outer IPv4 header is the same whether the inner packet is IPv4 or The outer IPv4 header is the same whether the inner packet is IPv4 or
IPv6. IPv6.
If no NAT device was detected in the path between the mobile node and If no NAT device was detected in the path between the mobile node and
the home agent then IPv6 packets are tunneled in an IPv4 header. The the home agent then IPv6 packets are tunneled in an IPv4 header,
unless the home agent forces UDP encapsulation using the F flag. The
content of the inner and outer headers are identical to the UDP content of the inner and outer headers are identical to the UDP
encapsulation case. encapsulation case.
Note that a mobile node MAY always tunnel binding updates in UDP when A mobile node MUST always tunnel binding updates in UDP when located
located in an IPv4-only network. Essentially, this process allows for in an IPv4-only network. Essentially, this process allows for
perpetual NAT detection. Alternatively, the mobile node MAY only send perpetual NAT detection. Similarly, the home agent MUST encapsulate
the first binding update in UDP and then remove the UDP header in binding acknowledgements in a UDP header whenever the binding update
future binding updates if a NAT were not detected to reduce is encapsulated in UDP.
overheads. This decision is left to the implementer's discretion. The
home agent MUST be able to receive both types of encapsulation.
In conclusion, the packet formats for the binding update and In conclusion, the packet formats for the binding update and
acknowledgement messages are shown below: acknowledgement messages are shown below:
A. Binding update received by the home agent: A. Binding update received by the home agent:
IPv4 header (src=V4ADDR, dst=HAADDR) IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
UDP header UDP header
IPv6 header (src=V4CoA, dst=HAADDR) IPv6 header (src=V4CoA, dst=HAADDR)
DST-OPT DST-OPT
HAO (IPv6 home address) HAO (IPv6 home address)
Mobility header Mobility header
BU [IPv4 HAO] BU [IPv4 HAO]
Where V4ADDR is either the IPv4 care-of address or the address Where V4ADDR is either the IPv4 care-of address or the address
provided by the NAT device. V4COA is the IPv4 care-of address of the provided by the NAT device. V4COA is the IPv4 care-of address of the
mobile node. HAO is the home address option and BU is the binding mobile node. HAO is the home address option and BU is the binding
update, which MAY contain the IPv4 home address option. update, which MAY contain the IPv4 home address option.
B. Binding acknowledgement sent by the home agent: B. Binding acknowledgement sent by the home agent:
IPv4 header (src=V4ADDR, dst=HAADDR) IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
[UDP header] (If V4ADDR != V4CoA) UDP header
IPv6 header (src=V4CoA, dst=HAADDR) IPv6 header (src=V4CoA, dst=HAADDR)
Route HRD Type 2 Route HDR Type 2
HOA (IPv6 home address) HOA (IPv6 home address)
Mobility header Mobility header
BA ([IPv4 ACK], NAT DET) BA ([IPv4 ACK], NAT DET)
Where HOA is IPv6 home address of the mobile node. The IPv4 ACK is Where HOA is IPv6 home address of the mobile node. The IPv4 ACK is
the IPv4 address acknowledgement option, which is only included if the IPv4 address acknowledgement option, which is only included if
the IPv4 home address option were present in the BU. The NAT DET is the IPv4 home address option were present in the BU. The NAT DET is
the NAT detection option, which MUST be present in the binding the NAT detection option, which MUST be present in the binding
acknowledgement message if the binding update was encapsulated in acknowledgement message if the binding update was encapsulated in
UDP. UDP.
4.2. Mobile node operation 4.2. NAT Keepalives
If a NAT is detected, the mobile node will need to refresh the NAT
bindings in order to be reachable from the home agent. NAT bindings
can be refreshed through sending and receiving traffic encapsulated
in UDP. However, if the mobile node is not active, it will need to
periodically send a message to the home agent in order to refresh the
NAT binding. This can be done using the binding update message. The
binding update/acknowledgement pair will ensure that the NAT bindings
are refreshed in a reliable manner.
There is no way for the mobile node to know the exact time of the NAT
binding. The default time suggested in this specification is
NATKATIMEOUT. If the home agent suggests a different refresh period
in the binding acknowledgement, the mobile node SHOULD use the value
suggested by the home agent.
If the refresh time in the NAT detection option in the binding
acknowledgement is set to the all 1s, the mobile node need not send
messages to refresh the NAT binding. However, the mobile node may
still be required to encapsulate traffic in UDP. This scenario may
take place when a NAT is not detected, but the home agent still
requires the mobile node to use UDP encapsulation.
It should be noted that a mobile node that does not need to be
reachable (i.e. only cares about the session continuity aspect of
Mobile IP) does not need to refresh NAT binding. In this case, the
mobile node would only be able to initiate communication with other
nodes.
4.3. Mobile node operation
In addition to the operations specified in [MIPv6] and [NEMO], this In addition to the operations specified in [MIPv6] and [NEMO], this
specification requires mobile nodes to be able to support an IPv4 specification requires mobile nodes to be able to support an IPv4
home address. The IPv4 home address is never sent in the IPv4-mapped home address. The IPv4 home address is never sent in the IPv4-mapped
IPv6 address format. This is primarily done to save bandwidth. IPv6 address format. This is primarily done to save bandwidth.
However, to simplify the mobile node's implementation, they may store However, to simplify the mobile node's implementation, they may store
the IPv4 home address in the binding update list, using the IPv4- the IPv4 home address in the binding update list, using the IPv4-
mapped IPv6 format. mapped IPv6 format.
When sending an IPv6 packet containing a binding update while When sending an IPv6 packet containing a binding update while
skipping to change at page 15, line 17 skipping to change at page 16, line 6
- The source address in the IPv6 header is the mobile node's IPv4- - The source address in the IPv6 header is the mobile node's IPv4-
mapped IPv6 address. That is, the same IPv4 address in the outer mapped IPv6 address. That is, the same IPv4 address in the outer
header is placed in the IPv6 header using the mapped address header is placed in the IPv6 header using the mapped address
format. format.
- The home address option contains the IPv6 home address as - The home address option contains the IPv6 home address as
specified in [MIPv6]. specified in [MIPv6].
- The IPv4 home address option MAY be included in the mobility - The IPv4 home address option MAY be included in the mobility
header. This option contains the IPv4 home address. If the mobile header. This option contains the IPv4 home address. If the mobile
node did not have a static home address it MAY include the node did not have a static home address it MAY include the
unspecified IPv4 address, which acts as a request for a dynamic unspecified IPv4 address, which acts as a request for a dynamic
IPv4 home address. IPv4 home address. Alternatively, one or more IPv4 home address
options may be included with requests for IPv4 prefixes (i.e. with
the Pref length set to a value less than 32).
- The IPv6 packet MUST be authenticated as per [MIPv6], based on the - The IPv6 packet MUST be authenticated as per [MIPv6], based on the
mobile node's IPv6 home address. mobile node's IPv6 home address.
When sending a binding update from a visited network that supports When sending a binding update from a visited network that supports
IPv6, the mobile node MUST follow the rules specified in [MIPv6]. In IPv6, the mobile node MUST follow the rules specified in [MIPv6]. In
addition, if the mobile node has an IPv4 home address or needs one, addition, if the mobile node has an IPv4 home address or needs one,
it should include the IPv4 home address option in the mobility it should include the IPv4 home address option in the mobility
header. If the mobile node already has a static IPv4 home address, header. If the mobile node already has a static IPv4 home address,
such address MUST be included in the IPv4 home address option. such address MUST be included in the IPv4 home address option.
Otherwise, if the mobile node needs a dynamic IPv4 address, it should Otherwise, if the mobile node needs a dynamic IPv4 address, it should
include the IPv4 unspecified address in the IPv4 home address option. include the IPv4 unspecified address in the IPv4 home address option.
When the mobile node receives a binding acknowledgement from the home When the mobile node receives a binding acknowledgement from the home
agent, it should follow the rules in [MIPv6] and [NEMO]. In addition, agent, it should follow the rules in [MIPv6] and [NEMO]. In addition,
the following actions MUST be made: the following actions MUST be made:
- If the mobility header includes and IPv4 address acknowledgement - If the mobility header includes an IPv4 address acknowledgement
option indicating success, the mobile node should create two option indicating success, the mobile node should create two
entries in its binding update list, one for the IPv6 home address entries in its binding update list, one for the IPv6 home address
and another for the IPv4 home address. and another for the IPv4 home address.
- If the NAT detection option were present, the mobile node - If the NAT detection option were present, the mobile node
MUST tunnel future packets in UDP and IPv4. This MUST be indicated MUST tunnel future packets in UDP and IPv4. This MUST be indicated
in the binding update list. in the binding update list.
- If no IPv4 address acknowledgement option were present, and an - If no IPv4 address acknowledgement option were present, and an
IPv4 home address option was present in the binding update, the IPv4 home address option was present in the binding update, the
mobile node MUST only create one binding update list entry for its mobile node MUST only create one binding update list entry for its
IPv6 home address. The mobile node MAY include the IPv4 home IPv6 home address. The mobile node MAY include the IPv4 home
skipping to change at page 16, line 7 skipping to change at page 16, line 49
node MUST NOT create an entry for that address in its binding node MUST NOT create an entry for that address in its binding
update list. The mobile node MAY include the IPv4 home address update list. The mobile node MAY include the IPv4 home address
option in future binding updates. option in future binding updates.
Note that a mobile node complying with this specification MUST Note that a mobile node complying with this specification MUST
configure an IPv4-mapped IPv6 address on its interface in the visited configure an IPv4-mapped IPv6 address on its interface in the visited
network. This is needed in order to allow the mobile node to receive network. This is needed in order to allow the mobile node to receive
binding acknowledgements from its home agent while located in an binding acknowledgements from its home agent while located in an
IPv4-only network. IPv4-only network.
4.3. Home agent operations 4.4. Home agent operations
In addition to the home agent specification in [MIPv6] and [NEMO], In addition to the home agent specification in [MIPv6] and [NEMO],
the home agent needs to be able to process the IPv4 home address the home agent needs to be able to process the IPv4 home address
option and generate the IPv4 address acknowledgement option. Both option and generate the IPv4 address acknowledgement option. Both
options are included in the mobility header. Furthermore, the home options are included in the mobility header. Furthermore, the home
agent MUST be able to detect the presence of a NAT device and agent MUST be able to detect the presence of a NAT device and
indicate that in the NAT detection option included in the binding indicate that in the NAT detection option included in the binding
acknowledgement. acknowledgement.
A home agent must also act as a proxy for address resolution in IPv4
for the registered IPv4 home addresses of mobile nodes it is serving.
Moreover, the administrative domain of the home agent is responsible
for advertising the routing information of registered IPv4 mobile
network prefixes of the mobile nodes.
In order to comply with this specification, the home agent MUST be In order to comply with this specification, the home agent MUST be
able to find the IPv4 home address of a mobile node when given the able to find the IPv4 home address of a mobile node when given the
IPv6 home address. That is, given an IPv6 home address, the home IPv6 home address. That is, given an IPv6 home address, the home
agent MUST store the corresponding IPv4 home address if a static one agent MUST store the corresponding IPv4 home address if a static one
is present. If a dynamic address were requested by the mobile node, is present. If a dynamic address were requested by the mobile node,
the home agent MUST store that address (associated with the IPv6 home the home agent MUST store that address (associated with the IPv6 home
address) after it's allocated to the mobile node. address) after it's allocated to the mobile node.
When the home agent receives a binding update encapsulated in UDP and When the home agent receives a binding update encapsulated in UDP and
containing the IPv4 home address option, it needs to follow all the containing the IPv4 home address option, it needs to follow all the
steps in [MIPv6] and [NEMO], in addition, the following checks MUST steps in [MIPv6] and [NEMO]. In addition, the following checks MUST
be done: be done:
- If the IPv4 care-of address in the IPv6 header is not the same as - If the IPv4 care-of address in the IPv6 header is not the same as
the IPv4 address in the source address in the IPv4 header then a the IPv4 address in the source address in the IPv4 header then a
NAT was in the path. This information should be flagged for the NAT was in the path. This information should be flagged for the
binding acknowledgement. binding acknowledgement.
- If the IPv4 home address option contains a valid unicast IPv4 - If the IPv4 home address option contains a valid unicast IPv4
address, the home agent MUST check that this address is allocated address, the home agent MUST check that this address is allocated
to the mobile node that has the IPv6 home address included in the to the mobile node that has the IPv6 home address included in the
skipping to change at page 17, line 27 skipping to change at page 18, line 24
If the care-of address of the mobile node were an IPv4 address, the If the care-of address of the mobile node were an IPv4 address, the
home agent MUST include this address in the destination address in home agent MUST include this address in the destination address in
the IPv6 header using the IPv4-mapped IPv6 format. If a NAT were the IPv6 header using the IPv4-mapped IPv6 format. If a NAT were
detected, the home agent MUST then encapsulate the packet in UDP and detected, the home agent MUST then encapsulate the packet in UDP and
an IPv4 header. The source address is set to the home agent's IPv4 an IPv4 header. The source address is set to the home agent's IPv4
address and the destination address is set to the address received in address and the destination address is set to the address received in
the source address of the IPv4 header encapsulating the binding the source address of the IPv4 header encapsulating the binding
update. update.
After creating a binding cache entry for the mobile node's home After creating a binding cache entry for the mobile node's home
addresses. All packets sent to the mobile node's home addresses are addresses, all packets sent to the mobile node's home addresses are
tunneled by the home agent to the mobile node's care-of address. If a tunneled by the home agent to the mobile node's care-of address. If a
NAT were detected, packets are encapsulated in UDP and IPv4. NAT were detected, packets are encapsulated in UDP and IPv4.
Otherwise, if the care-of address is an IPv4 address, and no NAT were Otherwise, if the care-of address is an IPv4 address, and no NAT were
detected, packets are encapsulated in an IPv4 header. detected, packets are encapsulated in an IPv4 header.
4.4. Correspondent node operations 4.5. Correspondent node operations
This specification has no impact on IPv4 or IPv6 correspondent nodes. This specification has no impact on IPv4 or IPv6 correspondent nodes.
5. Security considerations 5. Security considerations
This specification allows a mobile node to send one binding update This specification allows a mobile node to send one binding update
for its IPv6 and IPv4 home addresses. This is a slight deviation from for its IPv6 and IPv4 home addresses. This is a slight deviation from
[MIPv6] which requires one binding update per home address. However, [MIPv6] which requires one binding update per home address. However,
like [MIPv6], the IPsec security association needed to authenticate like [MIPv6], the IPsec security association needed to authenticate
the binding update is still based on the mobile node's IPv6 home the binding update is still based on the mobile node's IPv6 home
skipping to change at page 18, line 10 skipping to change at page 19, line 7
binding is the same as the IPv6 binding. binding is the same as the IPv6 binding.
In effect, associating the mobile node's IPv4 home address with its In effect, associating the mobile node's IPv4 home address with its
IPv6 home address moves the authorization of the binding update for IPv6 home address moves the authorization of the binding update for
the IPv4 address to the Mobile IPv6 implementation, which infers it the IPv4 address to the Mobile IPv6 implementation, which infers it
from the fact that mobile node has an IPv6 home address and the right from the fact that mobile node has an IPv6 home address and the right
credentials for sending an authentic binding update for such address. credentials for sending an authentic binding update for such address.
6. Protocol constants 6. Protocol constants
NATKATIMEOUT 30 seconds NATKATIMEOUT 110 seconds
7. Acknowledgements 7. Acknowledgements
TBD Thanks to Keiichi Shima for his valuable comments.
8. IANA considerations 8. IANA considerations
The specification requires the following allocations from IANA: The specification requires the following allocations from IANA:
- A UDP port is needed for the NAT traversal mechanism described in - A UDP port is needed for the NAT traversal mechanism described in
section 4.1. section 4.1.
- The IPv4 home address option described in section 3.1.1 requires an - The IPv4 home address option described in section 3.1.1 requires an
option type. This option is included in the Mobility header option type. This option is included in the Mobility header
described in [MIPv6]. described in [MIPv6].
- The IPv4 address acknowledgement option described in section 3.2.1 - The IPv4 address acknowledgement option described in section 3.2.1
skipping to change at page 21, line 4 skipping to change at page 21, line 46
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet-Draft expires April, 2006. This Internet-Draft expires September, 2006.
 End of changes. 52 change blocks. 
112 lines changed or deleted 165 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/