draft-ietf-v6ops-mech-v2-06.txt   draft-ietf-v6ops-mech-v2-07.txt 
INTERNET-DRAFT E. Nordmark INTERNET-DRAFT E. Nordmark
September 1, 2004 Sun Microsystems, Inc. March 29, 2005 Sun Microsystems, Inc.
Obsoletes: 2893 R. E. Gilligan Obsoletes: 2893 R. E. Gilligan
Intransa, Inc. Intransa, Inc.
Basic Transition Mechanisms for IPv6 Hosts and Routers Basic Transition Mechanisms for IPv6 Hosts and Routers
<draft-ietf-v6ops-mech-v2-06.txt> <draft-ietf-v6ops-mech-v2-07.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
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
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 draft expires on March 1, 2004. This draft expires on September 29, 2005.
Abstract Abstract
This document specifies IPv4 compatibility mechanisms that can be This document specifies IPv4 compatibility mechanisms that can be
implemented by IPv6 hosts and routers. Two mechanisms are specified, implemented by IPv6 hosts and routers. Two mechanisms are specified,
"dual stack" and configured tunneling. Dual stack implies providing "dual stack" and configured tunneling. Dual stack implies providing
complete implementations of both versions of the Internet Protocol complete implementations of both versions of the Internet Protocol
(IPv4 and IPv6) and configured tunneling provides a means to carry (IPv4 and IPv6) and configured tunneling provides a means to carry
IPv6 packets over unmodified IPv4 routing infrastructures. IPv6 packets over unmodified IPv4 routing infrastructures.
skipping to change at page 2, line 30 skipping to change at page 2, line 30
3.2.2. Dynamic Tunnel MTU............................. 10 3.2.2. Dynamic Tunnel MTU............................. 10
3.3. Hop Limit........................................... 11 3.3. Hop Limit........................................... 11
3.4. Handling ICMPv4 errors.............................. 12 3.4. Handling ICMPv4 errors.............................. 12
3.5. IPv4 Header Construction............................ 14 3.5. IPv4 Header Construction............................ 14
3.6. Decapsulation....................................... 15 3.6. Decapsulation....................................... 15
3.7. Link-Local Addresses................................ 18 3.7. Link-Local Addresses................................ 18
3.8. Neighbor Discovery over Tunnels..................... 19 3.8. Neighbor Discovery over Tunnels..................... 19
4. Threat Related to Source Address Spoofing................ 20 4. Threat Related to Source Address Spoofing................ 20
5. Security Considerations.................................. 21 5. IANA Considerations...................................... 21
6. Acknowledgments.......................................... 22 6. Security Considerations.................................. 21
7. References............................................... 23 7. Acknowledgments.......................................... 23
7.1. Normative References................................ 23
7.2. Informative References.............................. 23
8. Authors' Addresses....................................... 25 8. References............................................... 23
8.1. Normative References................................ 23
8.2. Informative References.............................. 23
9. Changes from RFC 2893.................................... 25 9. Authors' Addresses....................................... 25
9.1. Changes from draft-ietf-v6ops-mech-v2-00............ 28
9.2. Changes from draft-ietf-v6ops-mech-v2-01............ 29 10. Changes from RFC 2893................................... 26
9.3. Changes from draft-ietf-v6ops-mech-v2-02............ 30
9.4. Changes from draft-ietf-v6ops-mech-v2-03............ 31
9.5. Changes from draft-ietf-v6ops-mech-v2-04............ 31
9.6. Changes from draft-ietf-v6ops-mech-v2-05............ 31
1. Introduction 1. Introduction
The key to a successful IPv6 transition is compatibility with the The key to a successful IPv6 transition is compatibility with the
large installed base of IPv4 hosts and routers. Maintaining large installed base of IPv4 hosts and routers. Maintaining
compatibility with IPv4 while deploying IPv6 will streamline the task compatibility with IPv4 while deploying IPv6 will streamline the task
of transitioning the Internet to IPv6. This specification defines of transitioning the Internet to IPv6. This specification defines
two mechanisms that IPv6 hosts and routers may implement in order to two mechanisms that IPv6 hosts and routers may implement in order to
be compatible with IPv4 hosts and routers. be compatible with IPv4 hosts and routers.
skipping to change at page 10, line 17 skipping to change at page 10, line 17
decapsulator can reassemble or receive packets of that size. decapsulator can reassemble or receive packets of that size.
The selection of a good tunnel MTU depends on many factors; at least: The selection of a good tunnel MTU depends on many factors; at least:
- Whether the IPv4 protocol-41 packets will be transported over - Whether the IPv4 protocol-41 packets will be transported over
media which may have a lower path MTU (e.g., IPv4 Virtual media which may have a lower path MTU (e.g., IPv4 Virtual
Private Networks); then picking too high a value might lead to Private Networks); then picking too high a value might lead to
IPv4 fragmentation. IPv4 fragmentation.
- Whether the tunnel is used to transport IPv6 tunneled packets - Whether the tunnel is used to transport IPv6 tunneled packets
(e.g., a mobile node with an IPv4-in-IPv6 configured tunnel, and (e.g., a mobile node with an IPv6-in-IPv4 configured tunnel, and
an IPv6-in-IPv6 tunnel interface); then picking too low a value an IPv6-in-IPv6 tunnel interface); then picking too low a value
might lead to IPv6 fragmentation. might lead to IPv6 fragmentation.
If layered encapsulation is believed to be present, it may be prudent If layered encapsulation is believed to be present, it may be prudent
to consider supporting dynamic MTU determination instead as it is to consider supporting dynamic MTU determination instead as it is
able to minimize fragmentation and optimize packet sizes. able to minimize fragmentation and optimize packet sizes.
When using the static tunnel MTU the Don't Fragment bit MUST NOT be When using the static tunnel MTU the Don't Fragment bit MUST NOT be
set in the encapsulating IPv4 header. As a result the encapsulator set in the encapsulating IPv4 header. As a result the encapsulator
should not receive any ICMPv4 "packet too big" messages as a result should not receive any ICMPv4 "packet too big" messages as a result
skipping to change at page 12, line 10 skipping to change at page 12, line 10
The single-hop model is implemented by having the encapsulators and The single-hop model is implemented by having the encapsulators and
decapsulators process the IPv6 hop limit field as they would if they decapsulators process the IPv6 hop limit field as they would if they
were forwarding a packet on to any other datalink. That is, they were forwarding a packet on to any other datalink. That is, they
decrement the hop limit by 1 when forwarding an IPv6 packet. (The decrement the hop limit by 1 when forwarding an IPv6 packet. (The
originating node and final destination do not decrement the hop originating node and final destination do not decrement the hop
limit.) limit.)
The TTL of the encapsulating IPv4 header is selected in an The TTL of the encapsulating IPv4 header is selected in an
implementation dependent manner. The current suggested value is implementation dependent manner. The current suggested value is
published in the "Assigned Numbers" RFC [RFC3232][ASSIGNED]. The published in the "Assigned Numbers" RFC [RFC3232][ASSIGNED].
implementations MAY also consider using the value 255.
Implementations MAY provide a mechanism to allow the administrator to Implementations MAY provide a mechanism to allow the administrator to
configure the IPv4 TTL as the IP Tunnel MIB [RFC2667]. configure the IPv4 TTL as the IP Tunnel MIB [RFC2667].
3.4. Handling ICMPv4 errors 3.4. Handling ICMPv4 errors
In response to encapsulated packets it has sent into the tunnel, the In response to encapsulated packets it has sent into the tunnel, the
encapsulator might receive ICMPv4 error messages from IPv4 routers encapsulator might receive ICMPv4 error messages from IPv4 routers
inside the tunnel. These packets are addressed to the encapsulator inside the tunnel. These packets are addressed to the encapsulator
because it is the IPv4 source of the encapsulated packet. because it is the IPv4 source of the encapsulated packet.
skipping to change at page 21, line 5 skipping to change at page 21, line 5
the sender was some unrelated node. the sender was some unrelated node.
The solution to this is to have the decapsulator only accept The solution to this is to have the decapsulator only accept
encapsulated packets from the explicitly configured source address encapsulated packets from the explicitly configured source address
(i.e., the other end of the tunnel) as specified in section 3.6. (i.e., the other end of the tunnel) as specified in section 3.6.
While this does not provide complete protection in the case ingress While this does not provide complete protection in the case ingress
filtering has not been deployed, it does provide a significant filtering has not been deployed, it does provide a significant
increase in security. The issue and the remainder threats are increase in security. The issue and the remainder threats are
discussed at more length in Security Considerations. discussed at more length in Security Considerations.
5. Security Considerations 5. IANA Considerations
This memo makes no request to IANA. [[ RFC-editor: please remove this
section upon publication. ]]
6. Security Considerations
Generic security considerations of using IPv6 are discussed in a Generic security considerations of using IPv6 are discussed in a
separate document [V6SEC]. separate document [V6SEC].
An implementation of tunneling needs to be aware that while a tunnel An implementation of tunneling needs to be aware that while a tunnel
is a link (as defined in [RFC2460]), the threat model for a tunnel is a link (as defined in [RFC2460]), the threat model for a tunnel
might be rather different than for other links, since the tunnel might be rather different than for other links, since the tunnel
potentially includes all of the Internet. potentially includes all of the Internet.
Several mechanisms (e.g., Neighbor Discovery) depend on Hop Count Several mechanisms (e.g., Neighbor Discovery) depend on Hop Count
skipping to change at page 22, line 33 skipping to change at page 23, line 5
specification says that such packets MUST be discarded, and an ICMP specification says that such packets MUST be discarded, and an ICMP
error message SHOULD NOT be generated, unless the implementation error message SHOULD NOT be generated, unless the implementation
normally sends ICMP destination unreachable messages for unknown normally sends ICMP destination unreachable messages for unknown
protocols; in such a case, the same code MAY be sent. As should be protocols; in such a case, the same code MAY be sent. As should be
obvious, the not returning the same ICMP code if an error is returned obvious, the not returning the same ICMP code if an error is returned
for other protocols may hint that the IPv6 stack (or the protocol 41 for other protocols may hint that the IPv6 stack (or the protocol 41
tunneling processing) has been enabled -- the behaviour should be tunneling processing) has been enabled -- the behaviour should be
consistent on how the implementation otherwise behaves to be consistent on how the implementation otherwise behaves to be
transparent to probing. transparent to probing.
6. Acknowledgments 7. Acknowledgments
We would like to thank the members of the IPv6 working group, the We would like to thank the members of the IPv6 working group, the
Next Generation Transition (ngtrans) working group, and the v6ops Next Generation Transition (ngtrans) working group, and the v6ops
working group for their many contributions and extensive review of working group for their many contributions and extensive review of
this document. Special thanks are due to (in alphabetical order) Jim this document. Special thanks are due to (in alphabetical order) Jim
Bound, Ross Callon, Tim Chown, Alex Conta, Bob Hinden, Bill Manning, Bound, Ross Callon, Tim Chown, Alex Conta, Bob Hinden, Bill Manning,
John Moy, Mohan Parthasarathy, Chirayu Patel, Pekka Savola, and Fred John Moy, Mohan Parthasarathy, Chirayu Patel, Pekka Savola, and Fred
Templin for many helpful suggestions. Pekka Savola helped in editing Templin for many helpful suggestions. Pekka Savola helped in editing
the final revisions of the specification. the final revisions of the specification.
7. References 8. References
7.1. Normative References 8.1. Normative References
[RFC791] J. Postel, "Internet Protocol", RFC 791, September 1981. [RFC791] J. Postel, "Internet Protocol", RFC 791, September 1981.
[RFC1191] Mogul, J., and S. Deering., "Path MTU Discovery", RFC 1191, [RFC1191] Mogul, J., and S. Deering., "Path MTU Discovery", RFC 1191,
November 1990. November 1990.
[RFC1981] McCann, J., S. Deering, and J. Mogul. "Path MTU Discovery [RFC1981] McCann, J., S. Deering, and J. Mogul. "Path MTU Discovery
for IP version 6", RFC 1981, August 1996. for IP version 6", RFC 1981, August 1996.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[RFC2460] Deering, S., and Hinden, R. "Internet Protocol, Version 6 [RFC2460] Deering, S., and Hinden, R. "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2463] A. Conta, S. Deering, "Internet Control Message Protocol [RFC2463] A. Conta, S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6) (ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 2463, December 1998. Specification", RFC 2463, December 1998.
7.2. Informative References 8.2. Informative References
[ASSIGNED] IANA, "Assigned numbers online database", [ASSIGNED] IANA, "Assigned numbers online database",
http://www.iana.org/numbers.html http://www.iana.org/numbers.html
[DNSOPV6] Durand, A., Ihren, J., and Savola P., "Operational [DNSOPV6] Durand, A., Ihren, J., and Savola P., "Operational
Considerations and Issues with IPv6 DNS", draft-ietf-dnsop- Considerations and Issues with IPv6 DNS", draft-ietf-dnsop-
ipv6-dns-issues-09.txt, work-in-progress, August 2004. ipv6-dns-issues-10.txt, work-in-progress, October 2004.
[KM97] Kent, C., and J. Mogul, "Fragmentation Considered Harmful". [KM97] Kent, C., and J. Mogul, "Fragmentation Considered Harmful".
In Proc. SIGCOMM '87 Workshop on Frontiers in Computer In Proc. SIGCOMM '87 Workshop on Frontiers in Computer
Communications Technology. August 1987. Communications Technology. August 1987.
[V6SEC] P. Savola, "IPv6 Transition/Co-existence Security [V6SEC] P. Savola, "IPv6 Transition/Co-existence Security
Considerations", draft-savola-v6ops-security-overview- Considerations", draft-savola-v6ops-security-overview-
02.txt, work-in-progress, February 2004. 03.txt, work-in-progress, October 2004.
[V64IPSEC] Graveman, R., et al., "Using IPsec to Secure IPv6-over-IPv4 [V64IPSEC] Graveman, R., et al., "Using IPsec to Secure IPv6-over-IPv4
Tunnels", draft-tschofenig-v6ops-secure-tunnels-01.txt, Tunnels", draft-tschofenig-v6ops-secure-tunnels-03.txt,
work-in-progress, July 2004. work-in-progress, December 2004.
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication
Layers", STD 3, RFC 1122, October 1989. Layers", STD 3, RFC 1122, October 1989.
[RFC1435] S. Knowles, "IESG Advice from Experience with Path MTU [RFC1435] S. Knowles, "IESG Advice from Experience with Path MTU
Discovery", RFC 1435, March 1993. Discovery", RFC 1435, March 1993.
[RFC1812] F. Baker, "Requirements for IP Version 4 Routers", RFC 1812, [RFC1812] F. Baker, "Requirements for IP Version 4 Routers", RFC 1812,
June 1995. June 1995.
skipping to change at page 25, line 14 skipping to change at page 25, line 28
[RFC3513] Hinden, R., and S. Deering, "IP Version 6 Addressing [RFC3513] Hinden, R., and S. Deering, "IP Version 6 Addressing
Architecture", RFC 3513, April 2003. Architecture", RFC 3513, April 2003.
[RFC3596] Thomson, S., C. Huitema, V. Ksinant, and M. Souissi, "DNS [RFC3596] Thomson, S., C. Huitema, V. Ksinant, and M. Souissi, "DNS
Extensions to support IP version 6", RFC 3596, October 2003. Extensions to support IP version 6", RFC 3596, October 2003.
[RFC3704] Baker, F., and Savola P., "Ingress Filtering for Multihomed [RFC3704] Baker, F., and Savola P., "Ingress Filtering for Multihomed
Networks", RFC 3704, BCP 84, March 2004. Networks", RFC 3704, BCP 84, March 2004.
8. Authors' Addresses 9. Authors' Addresses
Erik Nordmark Erik Nordmark
Sun Microsystems Laboratories Sun Microsystems Laboratories
180, avenue de l'Europe 180, avenue de l'Europe
38334 SAINT ISMIER Cedex, France 38334 SAINT ISMIER Cedex, France
Tel : +33 (0)4 76 18 88 03 Tel : +33 (0)4 76 18 88 03
Fax : +33 (0)4 76 18 88 88 Fax : +33 (0)4 76 18 88 88
Email : erik.nordmark@sun.com Email : erik.nordmark@sun.com
Robert E. Gilligan Robert E. Gilligan
Intransa, Inc. Intransa, Inc.
2870 Zanker Rd., Suite 100 2870 Zanker Rd., Suite 100
San Jose, CA 95134 San Jose, CA 95134
Tel : +1 408 678 8600 Tel : +1 408 678 8600
Fax : +1 408 678 8800 Fax : +1 408 678 8800
Email : gilligan@intransa.com, gilligan@leaf.com Email : gilligan@intransa.com, gilligan@leaf.com
9. Changes from RFC 2893 10. Changes from RFC 2893
The motivation for the bulk of these changes are to simplify the The motivation for the bulk of these changes are to simplify the
document to only contain the mechanisms of wide-spread use. document to only contain the mechanisms of wide-spread use.
RFC 2893 contains a mechanism called automatic tunneling. But a much RFC 2893 contains a mechanism called automatic tunneling. But a much
more general mechanism is specified in RFC 3056 [RFC3056] which gives more general mechanism is specified in RFC 3056 [RFC3056] which gives
each node with a (global) IPv4 address a /48 IPv6 prefix i.e., enough each node with a (global) IPv4 address a /48 IPv6 prefix i.e., enough
for a whole site. for a whole site.
The following changes have been performed since RFC 2893: The following changes have been performed since RFC 2893:
skipping to change at page 28, line 4 skipping to change at page 28, line 11
- Add a note that the destination IPv4 address could also be a - Add a note that the destination IPv4 address could also be a
multicast address. multicast address.
- Make it RECOMMENDED to provide a toggle to perform strict - Make it RECOMMENDED to provide a toggle to perform strict
ingress filtering on an interface. ingress filtering on an interface.
- Generalize the text on the data in ICMPv4 messages. - Generalize the text on the data in ICMPv4 messages.
- Made a lot of miscellaneous editorial cleanups. - Made a lot of miscellaneous editorial cleanups.
9.1. Changes from draft-ietf-v6ops-mech-v2-00
[[ RFC-Editor note: remove the change history between the drafts
before publication. ]]
- Clarified in section 2.2 that there is no assumption that the
DNS server knows the IPv4/IPv6 capabilities of the requesting
node.
- Clarified in section 2.2 that a filtering resolver might want to
take into account external factors e.g., whether IPv6 interfaces
have been configured on the node.
- Clarified in section 2.3 that part of the motivation for the
section is that this is the opposite of common DNS practices in
IPv4; advertising unreachable IPv4 addresses in the DNS is
common.
- Removed the now artificial separation in a section on "common
tunneling techniques" and "configured tunneling" to make one
section on "configured tunneling".
- Restructured the section on tunnel MTU to make the relationship
between static tunnel MTU and dynamic tunnel MTU more clear.
This includes fixing the unclear language about "must be 1280
but may be configurable".
- Added warning about manually configuring large tunnel MTUs
causing excessive fragmentation.
- Added warning about IPv4 PMTU blackholes when using dynamic MTU.
- Clarified that when decapsulating the receiver must be liberal
and allow for padding of the encapsulated packet.
- Added example that when reflecting ICMPv4 errors as ICMPv6
errors it would be appropriate to use ICMPv6 unreachable type
with code "address unreachable" since an error from inside the
tunnel is in effect a link specific problem from IPv6's
perspective.
- Consolidated the text on ingress filtering and created a
separate section on the threat related to source address
spoofing through open decapsulators.
- Clarified "martian" filtering as follows: 0.0.0.0 should be
0.0.0.0/8, same for 127. (per RFC1812), and elaborated that the
broadcast address check includes both the 255.255.255.255
address and all the broadcast addresses of the decapsulator.
- Clarified that packets which fail the checks (such as verifying
the IPv4 source address, martian, and ingress filtering) on the
decapsulator should be silently dropped.
- Clarified that while source link layer address options and
target link layer address options are ignored in received ND
packets, the ND packets themselves are processed as normal.
9.2. Changes from draft-ietf-v6ops-mech-v2-01
- Removed unidirectional tunnels; assume all the tunnels are
bidirectional.
- Removed the definition of IPv4-compatible IPv6 addresses.
- Removed redundant text in the Hop Limit processing rules.
- Removed the guidelines for advertising addresses in DNS as
slightly out of scope, referring to another document for the
details.
- Removed the SHOULD requirement that the link-local addresses
should be formed based on IPv4 addresses.
- Added more discussion on the ICMPv4/6 Path MTU Discovery and the
required number of packet drops.
- Added a SHOULD for implementing a knob to be able to set the
source address of the tunnel, and add discussion why this is
useful.
- Added stronger wording for source address checks: both IPv4 and
IPv6 source addresses MUST be checked, and RPF-like ingress
filtering is optional.
- Rewrote security considerations to be more precise about the
threats of tunneling.
- Added a note that using TTL=255 when encapsulating might be
useful for decapsulation security checks later on.
- Added more discussion in Section 3.2 why using an "infinite"
IPv6 MTU leads to likely interoperability problems.
- Added an explicit requirement that if both MTU determination
methods are used, choosing one should be possible on a per-
tunnel basis.
- Clarified that ICMPv4 error handling is only applicable to
dynamic MTU determination.
- Specified Static MTU to default to a MTU of 1280 to 1480 bytes,
and that this may be configurable. Discussed the issues with
using Static MTU at more length.
- Specified minimal rules for IPv4 reassembly and IPv6 MRU to
enhance interoperability and to minimize blacholes.
- Made a lot of miscellaneous editorial cleanups.
9.3. Changes from draft-ietf-v6ops-mech-v2-02
- Removed DNS record filtering, and made it a SHOULD NOT;
summarized the DNS record ordering.
- Further clarified the usage of IPv6 RPF checks, as they
typically require manual configuration.
- Add a note on link-local address formation strategy to point out
that minimizing the probability of renumbering may be desirable.
- Clarify that with multiple IPv4 addresses, and the link-local
address formed based on one of them, the selection can be done
administratively or by the implementation.
- Refer to separate documents on generic IPv6 security
considerations and IPsec set-up details.
- Clarify that the IPv4 end-point address can be predictable in
some situations.
- Add a note that the destination IPv4 address could also be a
multicast address.
- Make it RECOMMENDED to provide a toggle to perform strict
ingress filtering on an interface.
9.4. Changes from draft-ietf-v6ops-mech-v2-03
- Generalize the text in section 3.4 about the data included in
ICMPv4 messages.
- Decree the address selection ordering mechanism out of scope for
this spec.
9.5. Changes from draft-ietf-v6ops-mech-v2-04
- Reword the definition of a configured tunnel to be more up-to-
date, and to specify that the tunnel is between addresses, not
hosts.
- Spell out that the source address is expected to be the
encapsulator's IPv4 address.
- Require that IP version of the data is 6, and that the length is
at least 40 bytes.
- Some minor editorial clarifications.
9.6. Changes from draft-ietf-v6ops-mech-v2-05
- Removed the requirement for IP version = 6 and the length checks
in *this* memo.
- Editorial clarifications.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 

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