draft-ietf-ngtrans-isatap-19.txt   draft-ietf-ngtrans-isatap-20.txt 
skipping to change at page 1, line 13 skipping to change at page 1, line 13
Network Working Group F. Templin Network Working Group F. Templin
Internet-Draft Nokia Internet-Draft Nokia
Expires: August 15, 2004 T. Gleeson Expires: August 15, 2004 T. Gleeson
Cisco Systems K.K. Cisco Systems K.K.
M. Talwar M. Talwar
D. Thaler D. Thaler
Microsoft Corporation Microsoft Corporation
February 16, 2004 February 16, 2004
Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
draft-ietf-ngtrans-isatap-19.txt draft-ietf-ngtrans-isatap-20.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. of Section 10 of RFC2026.
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
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 7, line 7 skipping to change at page 7, line 7
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+
5. Node Requirements 5. Node Requirements
ISATAP nodes observe the common functionality requirements in ISATAP nodes observe the common functionality requirements in
[NODEREQ] and the DNS requirements in ([MECH], section 2.2). They [NODEREQ] and the DNS requirements in ([MECH], section 2.2). They
also implement the additional features specified in this document. also implement the additional features specified in this document.
6. Addressing Requirements 6. Addressing Requirements
ISATAP nodes implement the addressing requirements found in
([NODEREQ], section 4.5). [RFC2462][RFC3484][ADDR] MUST be supported,
and [RFC3041] SHOULD be supported (configurable on a per-connection
basis).
6.1 ISATAP Interface Identifiers 6.1 ISATAP Interface Identifiers
ISATAP interface identifiers are constructed in Modified EUI-64 ISATAP interface identifiers are constructed in Modified EUI-64
format ([ADDR], appendix A). They are formed by concatenating the format ([ADDR], appendix A). They are formed by concatenating the
24-bit IANA OUI (00-00-5E), the 8-bit hexadecimal value 0xFE, and a 24-bit IANA OUI (00-00-5E), the 8-bit hexadecimal value 0xFE, and a
32-bit IPv4 address in network byte order. 32-bit IPv4 address in network byte order.
The format for ISATAP interface identifiers is given below (where 'u' The format for ISATAP interface identifiers is given below (where 'u'
is the IEEE univeral/local bit, 'g' is the IEEE group/individual bit, is the IEEE universal/local bit, 'g' is the IEEE group/individual
and the 'm' bits represent the concatenated IPv4 address): bit, and the 'm' bits represent the concatenated IPv4 address):
|0 1|1 3|3 4|4 6| |0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3| |0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
|000000ug00000000|0101111011111110|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| |000000ug00000000|0101111011111110|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
When the IPv4 address is known to be globally unique, the 'u' bit is When the IPv4 address is known to be globally unique, the 'u' bit is
set to 1; otherwise, the 'u' bit is set to 0 ([ADDR], section 2.5.1). set to 1; otherwise, the 'u' bit is set to 0 ([ADDR], section 2.5.1).
See: Appendix C for additional non-normative details. See: Appendix C for additional non-normative details.
skipping to change at page 11, line 8 skipping to change at page 11, line 8
"forwarding". "forwarding".
- other read-write objects in ipv6InterfaceEntry are configured as - other read-write objects in ipv6InterfaceEntry are configured as
for any IPv6 interface. for any IPv6 interface.
ISATAP interfaces create an ipv6RouterAdvertEntry and set its ISATAP interfaces create an ipv6RouterAdvertEntry and set its
ipv6RouterAdvertIfIndex object to the same value as ipv6RouterAdvertIfIndex object to the same value as
ipv6InterfaceIfIndex. Other objects in ipv6RouterAdvertEntry are ipv6InterfaceIfIndex. Other objects in ipv6RouterAdvertEntry are
configured as for any IPv6 router. configured as for any IPv6 router.
IPv6 address selection rules for ISATAP interfaces are specified in
[RFC3484].
7.5 Configured Tunnel Creation/Configuration 7.5 Configured Tunnel Creation/Configuration
Configured tunnels are normally created by the ISATAP daemon in Configured tunnels are normally created by the ISATAP daemon in
dynamic response to a tunnel creation request as an ISATAP dynamic response to a tunnel creation request as an ISATAP
interface's associated logical interface; they inherit the locator interface's associated logical interface; they inherit the locator
set of their associated ISATAP interface. Configured tunnels set the set of their associated ISATAP interface. Configured tunnels set the
following values for objects in tunnelIfEntry: following values for objects in tunnelIfEntry:
- tunnelIfEncapsMethod is set to an appropriate IANATunnelType - tunnelIfEncapsMethod is set to an appropriate IANATunnelType
value. value.
skipping to change at page 11, line 43 skipping to change at page 11, line 40
- ipv6InterfaceType is set to "tunnel". - ipv6InterfaceType is set to "tunnel".
- ipv6InterfacePhysicalAddress is set to an octet string of zero - ipv6InterfacePhysicalAddress is set to an octet string of zero
length to indicate that this IPv6 interface does not have a length to indicate that this IPv6 interface does not have a
physical address. physical address.
- other read-write objects in ipv6InterfaceEntry are configured as - other read-write objects in ipv6InterfaceEntry are configured as
for any IPv6 interface. for any IPv6 interface.
IPv6 address selection rules for configured tunnel interfaces are
specified in [RFC3484].
7.6 Reconfigurations Due to IPv4 Address Changes 7.6 Reconfigurations Due to IPv4 Address Changes
When an IPv4 address is removed from an interface, its corresponding When an IPv4 address is removed from an interface, its corresponding
locator SHOULD be removed from all locator sets via locator SHOULD be removed from all locator sets via
RcvTableDel(locator, NULL); tunnelIfEntrys that used the IPv4 address RcvTableDel(locator, NULL); tunnelIfEntrys that used the IPv4 address
as tunnelIfLocalInetAddress SHOULD also configure a different local as tunnelIfLocalInetAddress SHOULD also configure a different local
IPv4 address from their remaining locator set. IPv4 address from their remaining locator set.
When a new IPv4 address is added to an IPv4 interface, the node MAY When a new IPv4 address is added to an IPv4 interface, the node MAY
add the corresponding new locator to a tunnel interface's locator set add the corresponding new locator to a tunnel interface's locator set
skipping to change at page 15, line 21 skipping to change at page 15, line 15
4. Perform IPv4 ingress filtering (optional; disabled by default) 4. Perform IPv4 ingress filtering (optional; disabled by default)
then decapsulate the packet but do not discard encapsulating then decapsulate the packet but do not discard encapsulating
headers. If the IPv6 source address is invalid (see: [MECH], headers. If the IPv6 source address is invalid (see: [MECH],
section 3.6), silently discard the packet and return from section 3.6), silently discard the packet and return from
processing. processing.
For UDP port 3544 packets received on an ISATAP interface, if the For UDP port 3544 packets received on an ISATAP interface, if the
IPv6 source address is an ISATAP link local address with the 'u' IPv6 source address is an ISATAP link local address with the 'u'
bit set to 0 and an embedded IPv4 address that does not match the bit set to 0 and an embedded IPv4 address that does not match the
IPv4 source address (see: section 6), rewrite the IPv6 source IPv4 source address, rewrite the IPv6 source address to inform
address to inform upper layers of the sender's mapped UDP port upper layers of the sender's mapped UDP port number and IPv4
number and IPv4 source address. Specific rules for rewriting the source address. Specific rules for rewriting the IPv6 source
IPv6 source address are established during ISATAP interface address are established during ISATAP interface configuration.
configuration.
5. Perform ingress filtering on the IPv6 source address (see: 5. Perform ingress filtering on the IPv6 source address (see:
[MECH], section 3.6). Next, determine the correct transport [MECH], section 3.6). Next, determine the correct transport
protocol listener [FLOW] if the packet is destined to the protocol listener [FLOW] if the packet is destined to the
localhost; otherwise, perform an IPv6 forwarding table lookup and localhost; otherwise, perform an IPv6 forwarding table lookup and
site border/firewall filtering (see: [UNIQUE], section 6). site border/firewall filtering (see: [UNIQUE], section 6).
If the packet cannot be delivered, the driver SHOULD send an If the packet cannot be delivered, the driver SHOULD send an
ICMPv6 Destination Unreachable message ([RFC2463], section 3.2) ICMPv6 Destination Unreachable message ([RFC2463], section 3.2)
to the packet's source. The message SHOULD select as its source to the packet's source. The message SHOULD select as its source
skipping to change at page 17, line 12 skipping to change at page 17, line 8
stalled, an ICMPv6 Packet Too Big message [RFC1981] MAY be sent stalled, an ICMPv6 Packet Too Big message [RFC1981] MAY be sent
to the packet's source address with an MTU value likely to incur to the packet's source address with an MTU value likely to incur
successful reassembly. Some applications may realize greater successful reassembly. Some applications may realize greater
efficiency by accepting partial information from "INCOMPLETE" efficiency by accepting partial information from "INCOMPLETE"
packets (see: section 8.2) and requesting selective packets (see: section 8.2) and requesting selective
retransmission of missing portions. retransmission of missing portions.
9. Neighbor Discovery for ISATAP Interfaces 9. Neighbor Discovery for ISATAP Interfaces
ISATAP nodes use the neighbor discovery mechanisms specified in ISATAP nodes use the neighbor discovery mechanisms specified in
[RFC2461] along with securing mechanisms (e.g., [SEND]) to create/ [RFC2461] to create/change neighbor cache entries and to provide
change neighbor cache entries and to provide control plane signaling control plane signaling for automatic tunnel configuration. Securing
for automatic tunnel configuration. ISATAP interfaces also implement mechanisms for neighbor discovery messages (e.g., [RFC2402], [SEND])
the following specifications: are used according to the trust model appropriate for the given
deployment scenario [SENDPS]. ISATAP interfaces also implement the
following specifications:
9.1 Conceptual Model Of A Host 9.1 Conceptual Model Of A Host
To the list of Conceptual Data Structures ([RFC2461], section 5.1), To the list of Conceptual Data Structures ([RFC2461], section 5.1),
ISATAP interfaces add: ISATAP interfaces add:
Potential Router List Potential Router List
A set of entries about potential routers; used to support the A set of entries about potential routers; used to support the
mechanisms specified in section 9.2.2.1. Each entry ("PRL(i)") mechanisms specified in section 9.2.2.1. Each entry ("PRL(i)")
has an associated timer ("TIMER(i)"), and an IPv4 address has an associated timer ("TIMER(i)"), and an IPv4 address
("V4ADDR(i)") that represents a router's advertising ISATAP ("V4ADDR(i)") that represents a router's advertising ISATAP
interface. interface.
9.2 Router and Prefix Discovery 9.2 Router and Prefix Discovery
9.2.1 Router Specification 9.2.1 Router Specification
The Router Specification in ([RFC2461], section 6.2) is used. Router Solicited Router Advertisements sent on ISATAP interfaces are sent
Advertisements sent on ISATAP interfaces MAY include information directly to the soliciting node, i.e., they might not be received by
delegated via DHCPv6 [RFC3633]). Router Advertisements sent on ISATAP other nodes on the link.
interfaces MUST NOT include a prefix option containing a preferred
lifetime greater than the valid lifetime. Router Advertisements sent on ISATAP interfaces MAY include
information delegated via DHCPv6 [RFC3633].
Router Advertisements sent on ISATAP interfaces MUST NOT include a
prefix option containing a preferred lifetime greater than the valid
lifetime.
9.2.2 Host Specification 9.2.2 Host Specification
The Host Specification in ([RFC2461], section 6.3) is used. ISATAP The Host Specification in ([RFC2461], section 6.3) is used. ISATAP
interfaces add the following specifications: interfaces add the following specifications:
9.2.2.1 Host Variables 9.2.2.1 Host Variables
To the list of host variables ([RFC2461], section 6.3.2), ISATAP To the list of host variables ([RFC2461], section 6.3.2), ISATAP
interfaces add: interfaces add:
skipping to change at page 18, line 45 skipping to change at page 18, line 45
9.2.2.3 Processing Received Router Advertisements 9.2.2.3 Processing Received Router Advertisements
To the list of checks for validating Router Advertisement messages To the list of checks for validating Router Advertisement messages
([RFC2461], section 6.1.1), ISATAP interfaces add: ([RFC2461], section 6.1.1), ISATAP interfaces add:
- IP Source Address is an ISATAP link-local address that embeds - IP Source Address is an ISATAP link-local address that embeds
V4ADDR(i) for some PRL(i). V4ADDR(i) for some PRL(i).
Valid Router Advertisements received on an ISATAP interface are Valid Router Advertisements received on an ISATAP interface are
processed exactly as specified in ([RFC2461], section 6.3.4) except processed exactly as specified in ([RFC2461], section 6.3.4).
that, for unicast Router Advertisements that include an MTU option, [RFC3315] and [RFC3633] are stateful mechanisms associated with the M
the MTU value does not alter the ISATAP interface LinkMTU. Instead, and O bits.
the MTU value is recorded, e.g., in the IPv6 forwarding table. If the
IPv6 destination address is one of the node's own unicast addresses, For Router Advertisements that include an MTU option, the MTU value
the MTU value is recorded such that upper layer fragmentation does not alter the ISATAP interface LinkMTU. Instead, the MTU value
[RFC3542] will be used to reduce the size of the encapsulated packets is recorded, e.g., in the IPv6 forwarding table. If the IPv6
sent via the router. The recorded value is aged as for IPv6 path MTU destination address is one of the node's own unicast addresses, the
MTU value is recorded such that upper layer fragmentation [RFC3542]
will be used to reduce the size of the encapsulated packets sent via
the router. The recorded value is aged as for IPv6 path MTU
information [RFC1981]. information [RFC1981].
9.2.2.4 Sending Router Solicitations 9.2.2.4 Sending Router Solicitations
To the list of events after which Router Solicitation messages may be To the list of events after which Router Solicitation messages may be
sent ([RFC2461], section 6.3.7), ISATAP interfaces add: sent ([RFC2461], section 6.3.7), ISATAP interfaces add:
- TIMER(i) for some PRL(i) expires. - TIMER(i) for some PRL(i) expires.
Since unsolicited Router Advertisements may be incomplete (and, since Since unsolicited Router Advertisements may be incomplete and/or
multicast unsolicited Router Advertisements may not arrive) ISATAP absent, TIMER(i) MAY be used to schedule periodic Router Solicitation
nodes schedule periodic events to solicit Router Advertisements from events for certain PRL(i)'s.
certain PRL(i)'s. When this periodic solicitation is used, after
sending the initial solicitation and receiving a valid Router
Advertisement message from PRL(i) with a non-zero Router Lifetime the
node sets TIMER(i) to schedule the first periodic event.
The TIMER(i) value SHOULD be set such that the next periodic event When used, TIMER(i) SHOULD be set such that the next Router
will trigger a solicited Router Advertisement message before the Solicitation event will refresh remaining lifetimes stored for the
expiration of remaining lifetimes stored for this PRL(i), including PRL(i), including Router Lifetime, Valid Lifetimes received in Prefix
the Router Lifetime, Valid Lifetimes received in Prefix Information Information Options, and Route Lifetimes received in Route
Options, and Route Lifetimes received in Route Information Options Information Options [DEFLT]. TIMER(i) MUST be set to no less than
[DEFLT]. The TIMER(i) value MUST be set to no less than
MinRouterSolicitInterval seconds, where MinRouterSolicitInterval is MinRouterSolicitInterval seconds, where MinRouterSolicitInterval is
configurable for the node with a conservative default value. configurable for the node (or, for each PRL(i)) with a conservative
default value.
When TIMER(i) expires, the node sends Router Solicitation messages as When TIMER(i) expires, Router Solicitation messages are sent as
specified in ([RFC2461], section 6.3.7) except that the messages use specified in ([RFC2461], section 6.3.7) except that the messages are
an ISATAP link-local address that embeds V4ADDR(i) as the IPv6 sent directly to PRL(i), i.e., they might not be received by other
destination address (i.e., instead of the All-Routers multicast nodes on the link. While the node continues to use PRL(i) as a router
address). If remaining lifetimes for this PRL(i) have not yet expired (and, while PRL(i) continues to act as a router), the node resets
and the PRL(i) is still in use, TIMER(i) is reset as described above. TIMER(i) after each expiration as described above.
9.3 Address Resolution and Neighbor Unreachability Detection 9.3 Address Resolution and Neighbor Unreachability Detection
9.3.1 Address Resolution 9.3.1 Address Resolution
The specification in ([RFC2461], section 7.2) is used. ISATAP The specification in ([RFC2461], section 7.2) is used. ISATAP
addresses for which the neighbor's link-layer address cannot addresses for which the neighbor's link-layer address cannot
otherwise be determined (e.g., from a neighbor cache entry) are otherwise be determined (e.g., from a neighbor cache entry) are
resolved to link-layer addresses by a static computation, i.e., the resolved to link-layer addresses by a static computation, i.e., the
last four octets are treated as an IPv4 address. last four octets are treated as an IPv4 address.
skipping to change at page 20, line 13 skipping to change at page 20, line 13
confirmation, but this might not scale in all environments. confirmation, but this might not scale in all environments.
9.3.2 Neighbor Unreachability Detection 9.3.2 Neighbor Unreachability Detection
Hosts SHOULD perform Neighbor Unreachability Detection ([RFC2461], Hosts SHOULD perform Neighbor Unreachability Detection ([RFC2461],
section 7.3). Routers MAY perform neighbor unreachability detection, section 7.3). Routers MAY perform neighbor unreachability detection,
but this might not scale in all environments. but this might not scale in all environments.
10. Security considerations 10. Security considerations
Security considerations in the normative references apply. Also: The Security Considerations in the normative references, and in
([NODEREQ], section 8) apply. Also:
- ISATAP nodes observe the security considerations outlined in - ISATAP nodes observe the security considerations outlined in
[SENDPS]; use of (e.g., [RFC2402][RFC2406], etc.) is not always [SENDPS]; use of IPsec (e.g., [RFC2402][RFC2406], etc.) is not
feasible. always feasible.
- site border routers SHOULD install a reject route for the IPv6 - site border routers SHOULD install a reject route for the IPv6
prefix FC00::/7 to insure that packets with local IPv6 destination prefix FC00::/7 [UNIQUE] to insure that packets with local IPv6
addresses will not be forwarded outside of the site via a default destination addresses will not be forwarded outside of the site
route. via a default route.
- administrators MUST ensure that lists of IPv4 addresses - administrators MUST ensure that lists of IPv4 addresses
representing the advertising ISATAP interfaces of PRL members are representing the advertising ISATAP interfaces of PRL members are
well maintained. well maintained.
11. IANA Considerations 11. IANA Considerations
The IANA is instructed to specify the format for Modified EUI-64 The IANA is instructed to specify the format for Modified EUI-64
address construction ([ADDR], Appendix A) in the IANA Ethernet address construction ([ADDR], Appendix A) in the IANA Ethernet
Address Block. The text in Appendix C of this document is offered as Address Block. The text in Appendix C of this document is offered as
skipping to change at page 25, line 23 skipping to change at page 25, line 23
Type Name Reference Type Name Reference
---- ------------------------- --------- ---- ------------------------- ---------
1 Destination Unreachable [RFC2463] 1 Destination Unreachable [RFC2463]
Code 2 - beyond the scope of source address Code 2 - beyond the scope of source address
5 - source address failed ingress policy 5 - source address failed ingress policy
6 - reject route to destination 6 - reject route to destination
Normative References Normative References
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement [BCP14] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[STD3] Braden, R., "Requirements for Internet Hosts - Communication [STD3] Braden, R., "Requirements for Internet Hosts - Communication
Layers", STD 3, RFC 1122, October 1989. Layers", STD 3, RFC 1122, October 1989.
[STD5] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [STD5] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[STD6] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August [STD6] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
1980. 1980.
[RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for [RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for
IP version 6", RFC 1981, August 1996. IP version 6", RFC 1981, August 1996.
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998. for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2462] Thomson, S., and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2463] Conta, A., and S. Deering, "Internet Control Message Protocol [RFC2463] Conta, A., and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification",
RFC 2463, December 1998. RFC 2463, December 1998.
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
Domains without Explicit Tunnels", RFC 2529, March 1999. Domains without Explicit Tunnels", RFC 2529, March 1999.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January, 2001.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self- [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-
Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, Address Fixing (UNSAF) Across Network Address Translation", RFC 3424,
November 2002. November 2002.
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol [RFC3484] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003. version 6 (IPv6)", RFC 3484, February 2003.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493,
February 2003. February 2003.
skipping to change at page 27, line 7 skipping to change at page 27, line 11
[NODEREQ] Loughney, J., "IPv6 Node Requirements", draft-ietf-ipv6-node- [NODEREQ] Loughney, J., "IPv6 Node Requirements", draft-ietf-ipv6-node-
requirements, Work in Progress, October 2003. requirements, Work in Progress, October 2003.
[UNIQUE] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [UNIQUE] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", draft-ietf-ipv6-unique-local-addr, Work in Progress, Addresses", draft-ietf-ipv6-unique-local-addr, Work in Progress,
January 2004. January 2004.
Informative References Informative References
[BCP48] Dawkins, S., Montenegro, G., Kojo, M. and V. Magret, "End-to- [BCP48] Dawkins, S., Montenegro, G., Kojo, M. and V. Magret, "End-
end Performance Implications of Slow Links", BCP 48, RFC 3150, July to-end Performance Implications of Slow Links", BCP 48, RFC 3150,
2001. July 2001.
[STD13] Mockapetris, P., "Domain names - implementation and [STD13] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[RFC2491] Armitage, G., Schulter, P., Jork, M. and G. Harter, "IPv6 [RFC2491] Armitage, G., Schulter, P., Jork, M. and G. Harter, "IPv6
over Non-Broadcast Multiple Access (NBMA) networks", RFC 2491, over Non-Broadcast Multiple Access (NBMA) networks", RFC 2491,
January 1999. January 1999.
[RFC2492] Armitage, G., Schulter, P. and M. Jork, "IPv6 over ATM [RFC2492] Armitage, G., Schulter, P. and M. Jork, "IPv6 over ATM
Networks", RFC 2492, January 1999. Networks", RFC 2492, January 1999.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via
IPv4 Clouds", RFC 3056, February 2001. IPv4 Clouds", RFC 3056, February 2001.
skipping to change at page 29, line 14 skipping to change at page 29, line 14
Dave Thaler Dave Thaler
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052-6399 Redmond, WA 98052-6399
US US
Phone: +1 425 703 8835 Phone: +1 425 703 8835
EMail: dthaler@microsoft.com EMail: dthaler@microsoft.com
Intellectual Property Statement Full Copyright Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain
to the implementation or use of the technology described in this
document or the extent to which any license under such rights
might or might not be available; neither does it represent that it has
made any effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11. Copies of claims of rights
made available for publication and any assurances of licenses to be made
available, or the result of an attempt made to obtain a general license
or permission for the use of such proprietary rights by implementors or
users of this specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to practice this
standard. Please address the information to the IETF Executive Director.
The IETF has been notified of intellectual property rights claimed in Copyright (C) The Internet Society (2004). This document is subject to
regard to some or all of the specification contained in this document. the rights, licenses and restrictions contained in BCP 78 and except as
For more information consult the online list of claimed rights. set forth therein, the authors retain all their rights.
Full Copyright Statement This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright (C) The Internet Society (2004). All Rights Reserved. Intellectual Property
This document and translations of it may be copied and furnished to The IETF takes no position regarding the validity or scope of any
others, and derivative works that comment on or otherwise explain it or Intellectual Property Rights or other rights that might be claimed to
assist in its implementation may be prepared, copied, published pertain to the implementation or use of the technology described in this
and distributed, in whole or in part, without restriction of any kind, document or the extent to which any license under such rights might or
provided that the above copyright notice and this paragraph are included might not be available; nor does it represent that it has made any
on all such copies and derivative works. However, this document itself independent effort to identify any such rights. Information on the
may not be modified in any way, such as by removing the copyright notice procedures with respect to rights in RFC documents can be found in BCP
or references to the Internet Society or other Internet organizations, 78 and BCP 79.
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet Copies of IPR disclosures made to the IETF Secretariat and any
Standards process must be followed, or as required to translate it into assurances of licenses to be made available, or the result of an attempt
languages other than English. made to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can be
obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The limited permissions granted above are perpetual and will not be The IETF invites any interested party to bring to its attention any
revoked by the Internet Society or its successors or assignees. This copyrights, patents or patent applications, or other proprietary rights
document and the information contained herein is provided on an "AS IS" that may cover technology that may be required to implement this
basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE standard. Please address the information to the IETF at ietf-
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED ipr@ietf.org.
TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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