draft-ietf-mip6-nemo-v4traversal-01.txt   draft-ietf-mip6-nemo-v4traversal-02.txt 
MIP6 Working Group Hesham Soliman MIP6 Working Group Hesham Soliman (Ed.)
INTERNET-DRAFT George Tsirtsis INTERNET-DRAFT George Tsirtsis
Expires: September 2006 Flarion Expires: December 2006 Qualcomm
Vijay Deverapalli Vijay Deverapalli
Nokia Azaire Networks
James Kempf James Kempf
Docomo Labs Docomo Labs
Henrik Levkowetz Ericsson Henrik Levkowetz
Ericsson
Pascal Thubert Pascal Thubert
Cisco Cisco
Ryuji Wakikawa Ryuji Wakikawa
Keio University Keio University
March, 2006 June, 2006
Mobile IPv6 support for dual stack Mobile IPv6 support for dual stack
Hosts and Routers (DSMIPv6) Hosts and Routers (DSMIPv6)
draft-ietf-mip6-nemo-v4traversal-01.txt draft-ietf-mip6-nemo-v4traversal-02.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 1, line 44 skipping to change at page 1, line 47
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or cite them other than as "work in progress". material or 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/lid-abstracts.txt http://www.ietf.org/ietf/lid-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 document is a submission of the IETF MIP6 WG. Comments should be This document is a submission of the IETF MIP6 WG. Comments should be
directed to the IPv6 WG mailing list, mip6@ietf.org. directed to the MIP6 WG mailing list, mip6@ietf.org.
Abstract Abstract
The current Mobile IPv6 and NEMO specification support only IPv6. The current Mobile IPv6 and NEMO specification support only IPv6.
Hence, this specification extends those standards to allow the Hence, this specification extends those standards to allow the
registration of IPv4 addresses and prefixes, respectively, and the registration of IPv4 addresses and prefixes, respectively, and the
transport of both IPv4 and IPv6 packets over the tunnel to the HA. transport of both IPv4 and IPv6 packets over the tunnel to the HA.
This specification allows also the Mobile Node to roam over both IPv6 This specification allows also the Mobile Node to roam over both IPv6
and IPv4, including the case where Network Address Translation is and IPv4, including the case where Network Address Translation is
skipping to change at page 2, line 34 skipping to change at page 2, line 34
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..............................................13 4. Protocol operation..............................................13
4.1. NAT detection and traversal................................13 4.1. NAT detection and traversal................................13
4.2. NAT Keepalives.............................................14 4.2. NAT Keepalives.............................................15
4.3. Mobile node operation.........................................15 4.3. Mobile node operation.........................................15
4.4. Home agent operations.........................................16 4.3.1 Sending packets from a visited network.................17
4.5. Correspondent node operations.................................18 4.3.2 Movement detection in IPv4-only networks...............17
5. Security considerations.........................................18 4.4. Home agent operations.........................................17
6. Protocol constants..............................................19 4.4.1 Sending packets to the mobile node.....................19
7. Acknowledgements................................................19 4.5. Correspondent node operations.................................20
8. IANA considerations.............................................19 5. Security considerations.........................................20
9. References......................................................19 6. Protocol constants..............................................20
Authors' Addresses.................................................20 7. Acknowledgements................................................20
8. IANA considerations.............................................20
9. References......................................................21
Authors' Addresses.................................................21
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
skipping to change at page 10, line 42 skipping to change at page 10, line 42
3.1.1 IPv4 home address option 3.1.1 IPv4 home address option
This option is included in the Mobility Header including the binding This option is included in the Mobility Header including the binding
update message sent from the mobile node to a home agent or Mobility update message sent from the mobile node to a home agent or Mobility
Anchor Point. Anchor Point.
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 | Pref |Res| | Type | Length |Pref |P|Res|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 allocated to the mobile
home address. If only a single address is node. If only a single address is allocated,
needed/allowed, this field MUST be set to 32. this field MUST be set to 32. In the first
Otherwise, this field includes the IPv4 prefix binding update requesting a prefix, the field
Length. contains the prefix length requested. However,
Res This field is reserved for future use. It MUST in the following binding updates, this field
must contain the length of the prefix allocated.
P A flag indicating, when set, that the mobile
node requests a mobile network prefix. This flag
is only relevant for new requests, and must be
ignored for binding refreshes.
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.
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 mobile node
be requested by setting the address to 0.0.0.0 may choose to use this option to request a
and setting the Pref field to the requested prefix by setting the address to the All Zeroes
prefix length instead of the value 32. and setting the P flag. The mobile node could
then form an IPv4 home address based on the
allocated prefix. Alternatively, the mobile node
may use two different options, one for
requesting an address (Static or Dynamic) and
another for requesting a prefix.
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 the
the mobile node was not configured with one (i.e. if the unspecified case of Dynamic IPv4 home address configuration (i.e. if the
IPv4 address was included in the binding update). unspecified IPv4 address was included in the binding update).
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 | Status | Pref | Res | | Type | Length | Status | Pref | Res |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 home address | | IPv4 home address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type TBD Type TBD
Length 1 Length 1
Status Indicates success or failure for the IPv4 home Status Indicates success or failure for the IPv4 home
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
skipping to change at page 12, line 4 skipping to change at page 12, line 19
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 133 Prefix allocation unauthorized
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 set to zero and ignored in case of failure. be set to zero and ignored in case of failure.
This field overrides what the mobile node This field overrides what the mobile node
requested (if not equal to the requested requested (if not equal to the requested
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.
skipping to change at page 16, line 8 skipping to change at page 16, line 30
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. Alternatively, one or more 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 options may be included with requests for IPv4 prefixes (i.e. with
the Pref length set to a value less than 32). the P flag set.).
- 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
skipping to change at page 16, line 43 skipping to change at page 17, line 13
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
address option in future binding updates. address option in future binding updates.
- If an IPv4 address acknowledgement option were present and it - If an IPv4 address acknowledgement option were present and it
indicates failure for the IPv4 home address binding, the mobile indicates failure for the IPv4 home address binding, the mobile
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 4.3.1 Sending packets from a visited network.
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 When the mobile node is located in an IPv6-enabled network it sends
binding acknowledgements from its home agent while located in an and receives IPv6 packets as described in [MIPv6]. IPv4 traffic is
IPv4-only network. encapsulated in IPv6 packets to the home agent.
When the mobile node is located in an IPv4 only network, it will send
IPv6 packets to its home agent according to the following format:
IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
[UDP header]
IPv6 header (src=V6HoA, dst=CN)
Upper layer protocols
Where the UDP header is only used if a NAT were detected between the
mobile node and the home agent, or if the home agent forced UDP
encapsulation.
Similarly, IPv4 packets are sent according to the following format:
IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
[UDP header]
IPv4 header (src=V4HoA, dst=V4CN)
Upper layer protocols
Where the UDP header is only used if a NAT were detected between the
mobile node and the home agent, or if the home agent forced UDP
encapsulation.
4.3.2 Movement detection in IPv4-only networks
[MIPv6] describes movement detection mostly based on IPv6-specific
triggers. Such triggers would not be available in an IPv4-only
network. Hence, a mobile node located in an IPv4-only network SHOULD
use [DNAv4] for guidance on movement detection mechanisms in IPv4-
only networks.
4.4. 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.
skipping to change at page 18, line 30 skipping to change at page 19, line 33
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.1 Sending packets to the mobile node
The home agent follows the rules specified in [MIPv6] for sending
IPv6 packets to mobile nodes located in IPv6 networks. When sending
IPv4 packets to When mobile nodes in an IPv6 network, the home agent
must encapsulate the IPv4 packets in IPv6.
When sending IPv6 packets to a mobile node located in an IPv4
network, the home agent must follow the following format:
IPv4 header (src= HA_V4ADDR, dst= V4CoA)
[UDP header]
IPv6 header (src=CN, dst= V6HoA)
Upper layer protocols
Where the UDP header is only included if a NAT were detected between
the mobile node and the home agent, or if the home agent forced UDP
encapsulation.
When sending IPv4 packets to a mobile node located in an IPv4
network, the home agent must follow the following format:
IPv4 header (src= HA_V4ADDR, dst= V4CoA)
[UDP header]
IPv4 header (src=V4CN, dst= V4HoA)
Upper layer protocols
Where the UDP header is only included if a NAT were detected between
the mobile node and home agent, or if the home agent forced UDP
encapsulation.
4.5. 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
skipping to change at page 19, line 11 skipping to change at page 20, line 44
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 110 seconds NATKATIMEOUT 110 seconds
7. Acknowledgements 7. Acknowledgements
Thanks to Keiichi Shima for his valuable comments. Thanks to Keiichi Shima for his comments on the draft.
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 20, line 17 skipping to change at page 21, line 50
Protoect Mobile IPv6 Signaling between Mobile Nodes and Home Protoect Mobile IPv6 Signaling between Mobile Nodes and Home
Agents", RFC 3776, June 2004. Agents", RFC 3776, June 2004.
[SNRIO] Larsson, T., Gustafsson, E., and H. Levkowetz, "Use of MIPv6 [SNRIO] Larsson, T., Gustafsson, E., and H. Levkowetz, "Use of MIPv6
in IPv4 and MIPv4 in IPv6 networks", draft-larsson-v6ops- in IPv4 and MIPv4 in IPv6 networks", draft-larsson-v6ops-
mip-scenarios-01.txt, February 2004. mip-scenarios-01.txt, February 2004.
Authors' Addresses Authors' Addresses
Hesham Soliman Hesham Soliman
Flarion Technologies Qualcomm-Flarion Technologies
Phone: +1 908 997 9775 E-mail: Hesham@Qualcomm.com
E-mail: H.Soliman@Flarion.com
George Tsirtsis George Tsirtsis
Flarion Technologies Qualcomm-Flarion Technologies
Phone: +1 908 947 7059 Phone: +1 908 947 7059
E-mail1: G.Tsirtsis@Flarion.com E-mail1: G.Tsirtsis@Qualcomm.com
E-mail2: tsirtsisg@yahoo.com E-mail2: tsirtsisg@yahoo.com
Vijay Devarapalli Vijay Devarapalli
313 Fairchild Drive
Mountain View, CA 94043
E-mail: vijay.devarapalli@nokia.com E-mail: vijay.devarapalli@nokia.com
James Kempf
DoCoMo Labs USA DoCoMo Labs USA
181 Metro Drive 181 Metro Drive
Suite 300 Suite 300
San Jose, CA San Jose, CA
95110 95110
E-mail: kempf@docomolabs-usa.com E-mail: kempf@docomolabs-usa.com
Henrik Levkowetz Henrik Levkowetz
Ericsson Research Ericsson Research
Torshamsgatan 23 Torshamsgatan 23
skipping to change at page 22, line 4 skipping to change at page 23, line 33
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 (2006). 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 September, 2006. This Internet-Draft expires December, 2006.
 End of changes. 29 change blocks. 
46 lines changed or deleted 126 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/