draft-ietf-hip-multihoming-10.txt   draft-ietf-hip-multihoming-11.txt 
Network Working Group T. Henderson, Ed. Network Working Group T. Henderson, Ed.
Internet-Draft University of Washington Internet-Draft University of Washington
Intended status: Standards Track C. Vogt Intended status: Standards Track C. Vogt
Expires: January 25, 2017 Independent Expires: March 12, 2017 Independent
J. Arkko J. Arkko
Ericsson Ericsson
July 24, 2016 September 8, 2016
Host Multihoming with the Host Identity Protocol Host Multihoming with the Host Identity Protocol
draft-ietf-hip-multihoming-10 draft-ietf-hip-multihoming-11
Abstract Abstract
This document defines host multihoming extensions to the Host This document defines host multihoming extensions to the Host
Identity Protocol (HIP), by leveraging protocol components defined Identity Protocol (HIP), by leveraging protocol components defined
for host mobility. for host mobility.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on January 25, 2017. This Internet-Draft will expire on March 12, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 28
4.6. Site Multihoming . . . . . . . . . . . . . . . . . . . . 9 4.6. Site Multihoming . . . . . . . . . . . . . . . . . . . . 9
4.7. Dual Host Multihoming . . . . . . . . . . . . . . . . . . 10 4.7. Dual Host Multihoming . . . . . . . . . . . . . . . . . . 10
4.8. Combined Mobility and Multihoming . . . . . . . . . . . . 10 4.8. Combined Mobility and Multihoming . . . . . . . . . . . . 10
4.9. Initiating the Protocol in R1, I2, or R2 . . . . . . . . 11 4.9. Initiating the Protocol in R1, I2, or R2 . . . . . . . . 11
4.10. Using LOCATOR_SETs across Addressing Realms . . . . . . . 12 4.10. Using LOCATOR_SETs across Addressing Realms . . . . . . . 12
4.11. Interaction with Security Associations . . . . . . . . . 13 4.11. Interaction with Security Associations . . . . . . . . . 13
5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 13 5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Sending LOCATOR_SETs . . . . . . . . . . . . . . . . . . 13 5.1. Sending LOCATOR_SETs . . . . . . . . . . . . . . . . . . 13
5.2. Handling Received LOCATOR_SETs . . . . . . . . . . . . . 15 5.2. Handling Received LOCATOR_SETs . . . . . . . . . . . . . 15
5.3. Verifying Address Reachability . . . . . . . . . . . . . 17 5.3. Verifying Address Reachability . . . . . . . . . . . . . 17
5.4. Changing the Preferred Locator . . . . . . . . . . . . . 17 5.4. Changing the Preferred Locator . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 20 8. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative references . . . . . . . . . . . . . . . . . . 20 9.1. Normative references . . . . . . . . . . . . . . . . . . 20
9.2. Informative references . . . . . . . . . . . . . . . . . 21 9.2. Informative references . . . . . . . . . . . . . . . . . 21
Appendix A. Document Revision History . . . . . . . . . . . . . 22 Appendix A. Document Revision History . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction and Scope 1. Introduction and Scope
skipping to change at page 4, line 27 skipping to change at page 4, line 27
multihoming, it does not define all possible policies and procedures, multihoming, it does not define all possible policies and procedures,
such as which locators to choose when more than one is available, the such as which locators to choose when more than one is available, the
operation of simultaneous mobility and multihoming, source address operation of simultaneous mobility and multihoming, source address
selection policies (beyond those specified in [RFC6724]), and the selection policies (beyond those specified in [RFC6724]), and the
implications of multihoming on transport protocols. implications of multihoming on transport protocols.
4. Protocol Overview 4. Protocol Overview
In this section, we briefly introduce a number of usage scenarios for In this section, we briefly introduce a number of usage scenarios for
HIP multihoming. These scenarios assume that HIP is being used with HIP multihoming. These scenarios assume that HIP is being used with
the ESP transform [RFC7402], although other scenarios may be defined the ESP transport [RFC7402], although other scenarios may be defined
in the future. To understand these usage scenarios, the reader in the future. To understand these usage scenarios, the reader
should be at least minimally familiar with the HIP protocol should be at least minimally familiar with the HIP protocol
specification [RFC7401], the use of the ESP transport format specification [RFC7401], the use of the ESP transport format
[RFC7402], and the HIP mobility specification [RFC7402], and the HIP mobility specification
[I-D.ietf-hip-rfc5206-bis]. However, for the (relatively) [I-D.ietf-hip-rfc5206-bis]. However, for the (relatively)
uninitiated reader, it is most important to keep in mind that in HIP uninitiated reader, it is most important to keep in mind that in HIP
the actual payload traffic is protected with ESP, and that the ESP the actual payload traffic is protected with ESP, and that the ESP
SPI acts as an index to the right host-to-host context. Security Parameter Index (SPI) acts as an index to the right host-to-
host context.
4.1. Background 4.1. Background
The multihoming scenarios can be explained in contrast to the non- The multihoming scenarios can be explained in contrast to the non-
multihoming case described in the base protocol specification. We multihoming case described in the base protocol specification. We
review the pertinent details here. In the base specification when review the pertinent details here. In the base specification when
used with the ESP transport format, the HIP base exchange will set up used with the ESP transport format, the HIP base exchange will set up
a single SA in each direction. The IP addresses associated with the a single SA in each direction. The IP addresses associated with the
SAs are the same as those used to convey the HIP packets. For data SAs are the same as those used to convey the HIP packets. For data
traffic, a security policy database (SPD) and security association traffic, a security policy database (SPD) and security association
skipping to change at page 6, line 23 skipping to change at page 6, line 24
address selection decisions. address selection decisions.
Hosts that use link-local addresses as source addresses in their HIP Hosts that use link-local addresses as source addresses in their HIP
handshakes may not be reachable by a mobile peer. Such hosts SHOULD handshakes may not be reachable by a mobile peer. Such hosts SHOULD
provide a globally routable address either in the initial handshake provide a globally routable address either in the initial handshake
or via the LOCATOR_SET parameter. or via the LOCATOR_SET parameter.
To support mobility, as described in the HIP mobility specification To support mobility, as described in the HIP mobility specification
[I-D.ietf-hip-rfc5206-bis], the LOCATOR_SET may be sent in a HIP [I-D.ietf-hip-rfc5206-bis], the LOCATOR_SET may be sent in a HIP
UPDATE packet. To support multihoming, the LOCATOR_SET may also be UPDATE packet. To support multihoming, the LOCATOR_SET may also be
sent in R1, I2, or R2 packets. The reason to consider to send sent in R1, I2, or R2 packets defined in the HIP protocol
LOCATOR_SET parameters in the base exchange packets is to convey all specification [RFC7401]. The reason to consider to send LOCATOR_SET
usable addresses for fault-tolerance or load balancing parameters in the base exchange packets is to convey all usable
considerations. addresses for fault-tolerance or load balancing considerations.
4.3. Multiple Security Associations 4.3. Multiple Security Associations
When multiple addresses are available between peer hosts, a question When multiple addresses are available between peer hosts, a question
that arises is whether to use one or multiple SAs. The intent of that arises is whether to use one or multiple SAs. The intent of
this specification is to support different use cases but to leave the this specification is to support different use cases but to leave the
policy decision to the hosts. policy decision to the hosts.
When one host has n addresses and the other host has m addresses, it When one host has n addresses and the other host has m addresses, it
is possible to set up as many as (n * m) SAs in each direction. In is possible to set up as many as (n * m) SAs in each direction. In
such a case, every combination of source and destination IP address such a case, every combination of source and destination IP address
would have a unique SA, and the possibility of reordering of would have a unique SA, and the possibility of reordering of
datagrams on each SA will be lessened (ESP SAs may have an anti- datagrams on each SA will be lessened (ESP SAs may have an anti-
replay window sensitive to reordering). However, the downside to replay window [RFC4303] sensitive to reordering). However, the
creating a mesh of SAs is the signaling overhead required (for downside to creating a mesh of SAs is the signaling overhead required
exchanging UPDATE messages conveying ESP_INFO parameters) and the (for exchanging UPDATE messages conveying ESP_INFO parameters) and
state maintenance required in the SPD/SAD. the state maintenance required in the SPD/SAD.
For load balancing, when multiple paths are to be used in parallel, For load balancing, when multiple paths are to be used in parallel,
it may make sense to create different SAs for different paths. In it may make sense to create different SAs for different paths. In
this use case, while a full mesh of 2 * (n * m) SAs may not be this use case, while a full mesh of 2 * (n * m) SAs may not be
required, it may be beneficial to create one SA pair per load- required, it may be beneficial to create one SA pair per load-
balanced path to avoid anti-replay window issues. balanced path to avoid anti-replay window issues.
For fault tolerance, it is more likely that a single SA can be used For fault tolerance, it is more likely that a single SA can be used
and multiple IP addresses associated with that SA, and the and multiple IP addresses associated with that SA, and the
alternative addresses used only upon failure detection of the alternative addresses used only upon failure detection of the
skipping to change at page 7, line 31 skipping to change at page 7, line 31
A (mobile or stationary) host may have more than one interface or A (mobile or stationary) host may have more than one interface or
global address. The host may choose to notify the peer host of the global address. The host may choose to notify the peer host of the
additional interface or address by using the LOCATOR_SET parameter. additional interface or address by using the LOCATOR_SET parameter.
The LOCATOR_SET parameter may be included in an I2, R1, or R2 packet, The LOCATOR_SET parameter may be included in an I2, R1, or R2 packet,
or may be conveyed, after the base exchange completes in an UPDATE or may be conveyed, after the base exchange completes in an UPDATE
packet. packet.
When more than one locator is provided to the peer host, the host MAY When more than one locator is provided to the peer host, the host MAY
indicate which locator is preferred (the locator on which the host indicate which locator is preferred (the locator on which the host
prefers to receive traffic). By default, the addresses used in the prefers to receive traffic). By default, the address that a host
base exchange are preferred until indicated otherwise. It may be the uses in the base exchange is its preferred locator (for the address
case that the host does not express any preferred locators. family and address scope in use during the base exchange) until
indicated otherwise. It may be the case that the host does not
express any preferred locators.
In the multihoming case, the sender may also have multiple valid In the multihoming case, the sender may also have multiple valid
locators from which to source traffic. In practice, a HIP locators from which to source traffic. In practice, a HIP
association in a multihoming configuration may have both a preferred association in a multihoming configuration may have both a preferred
peer locator and a preferred local locator, although rules for source peer locator and a preferred local locator. The host should try to
address selection should ultimately govern the selection of the use the peer's preferred locator unless policy or other circumstances
source locator based on the destination locator. prevent such usage. A preferred local locator may be overridden if
source address selection rules on the destination address (peer's
preferred locator) suggest the use of a different source address.
Although the protocol may allow for configurations in which there is Although the protocol may allow for configurations in which there is
an asymmetric number of SAs between the hosts (e.g., one host has two an asymmetric number of SAs between the hosts (e.g., one host has two
interfaces and two inbound SAs, while the peer has one interface and interfaces and two inbound SAs, while the peer has one interface and
one inbound SA), it is RECOMMENDED that inbound and outbound SAs be one inbound SA), it is RECOMMENDED that inbound and outbound SAs be
created pairwise between hosts. When an ESP_INFO arrives to rekey a created pairwise between hosts. When an ESP_INFO arrives to rekey a
particular outbound SA, the corresponding inbound SA should be also particular outbound SA, the corresponding inbound SA should be also
rekeyed at that time. rekeyed at that time.
Consider the case of two hosts, one single-homed and one multihomed. Consider the case of two hosts, one single-homed and one multihomed.
skipping to change at page 8, line 28 skipping to change at page 8, line 32
UPDATE(LOCATOR_SET, SEQ) UPDATE(LOCATOR_SET, SEQ)
-----------------------------------> ----------------------------------->
UPDATE(ACK) UPDATE(ACK)
<----------------------------------- <-----------------------------------
Figure 1: Basic Multihoming Scenario Figure 1: Basic Multihoming Scenario
In this scenario, the peer host associates the multiple addresses In this scenario, the peer host associates the multiple addresses
with the SA pair between it and the multihomed host. It may also with the SA pair between it and the multihomed host. It may also
undergo address verification procedures to transition the addresses undergo address verification procedures to transition the addresses
to ACTIVE statte. For inbound data traffic, it may choose to use the to ACTIVE state. For inbound data traffic, it may choose to use the
addresses along with the SPI as selectors. For outbound data addresses along with the SPI as selectors. For outbound data
traffic, it must choose among the available addresses of the traffic, it must choose among the available addresses of the
multihomed host, considering the state of address verification multihomed host, considering the state of address verification
[I-D.ietf-hip-rfc5206-bis] of each address, and also considering [I-D.ietf-hip-rfc5206-bis] of each address, and also considering
available information about whether an address is in a working state. available information about whether an address is in a working state.
4.5. Host Multihoming for Load Balancing 4.5. Host Multihoming for Load Balancing
A multihomed host may decide to set up new SA pairs corresponding to A multihomed host may decide to set up new SA pairs corresponding to
new addresses, for the purpose of load balancing. The decision to new addresses, for the purpose of load balancing. The decision to
skipping to change at page 13, line 47 skipping to change at page 13, line 47
5. Processing Rules 5. Processing Rules
Basic processing rules for the LOCATOR_SET parameter are specified in Basic processing rules for the LOCATOR_SET parameter are specified in
[I-D.ietf-hip-rfc5206-bis]. This document focuses on multihoming- [I-D.ietf-hip-rfc5206-bis]. This document focuses on multihoming-
specific rules. specific rules.
5.1. Sending LOCATOR_SETs 5.1. Sending LOCATOR_SETs
The decision of when to send a LOCATOR_SET, and which addresses to The decision of when to send a LOCATOR_SET, and which addresses to
include, is a local policy issue. [I-D.ietf-hip-rfc5206-bis] include, is a local policy issue. [I-D.ietf-hip-rfc5206-bis]
recommends that a host send a LOCATOR_SET whenever it recognizes a recommends that a host should send a LOCATOR_SET whenever it
change of its IP addresses in use on an active HIP association, and recognizes a change of its IP addresses in use on an active HIP
assumes that the change is going to last at least for a few seconds. association, and assumes that the change is going to last at least
It is possible to delay the exposure of additional locators to the for a few seconds. It is possible to delay the exposure of
peer, and to send data from previously unannounced locators, as might additional locators to the peer, and to send data from previously
arise in certain mobility or multihoming situations. unannounced locators, as might arise in certain mobility or
multihoming situations.
When a host decides to inform its peers about changes in its IP When a host decides to inform its peers about changes in its IP
addresses, it has to decide how to group the various addresses with addresses, it has to decide how to group the various addresses with
SPIs. The grouping should consider also whether middlebox SPIs. The grouping should consider also whether middlebox
interaction requires sending the same LOCATOR_SET in separate UPDATEs interaction requires sending the same LOCATOR_SET in separate UPDATEs
on different paths. Since each SPI is associated with a different on different paths. Since each SPI is associated with a different
Security Association, the grouping policy may also be based on ESP Security Association, the grouping policy may also be based on ESP
anti-replay protection considerations. In the typical case, simply anti-replay protection considerations. In the typical case, simply
basing the grouping on actual kernel level physical and logical basing the grouping on actual kernel level physical and logical
interfaces may be the best policy. Grouping policy is outside of the interfaces may be the best policy. Grouping policy is outside of the
skipping to change at page 16, line 45 skipping to change at page 16, line 50
address therein is a legal unicast or anycast address. That is, the address therein is a legal unicast or anycast address. That is, the
address MUST NOT be a broadcast or multicast address. Note that some address MUST NOT be a broadcast or multicast address. Note that some
implementations MAY accept addresses that indicate the local host, implementations MAY accept addresses that indicate the local host,
since it may be allowed that the host runs HIP with itself. since it may be allowed that the host runs HIP with itself.
For each Type "1" address listed in the LOCATOR_SET parameter, the For each Type "1" address listed in the LOCATOR_SET parameter, the
host checks whether the address is already bound to the SPI host checks whether the address is already bound to the SPI
indicated. If the address is already bound, its lifetime is updated. indicated. If the address is already bound, its lifetime is updated.
If the status of the address is DEPRECATED, the status is changed to If the status of the address is DEPRECATED, the status is changed to
UNVERIFIED. If the address is not already bound, the address is UNVERIFIED. If the address is not already bound, the address is
added, and its status is set to UNVERIFIED. Mark all addresses added, and its status is set to UNVERIFIED. If there exist remaining
corresponding to the SPI that were NOT listed in the LOCATOR_SET addresses corresponding to the SPI that were NOT listed in the
parameter as DEPRECATED. LOCATOR_SET parameter, the host sets the status of such addresses to
DEPRECATED.
For each Type "0" address listed in the LOCATOR_SET parameter, if the For each Type "0" address listed in the LOCATOR_SET parameter, if the
status of the address is DEPRECATED, or the address was not status of the address is DEPRECATED, or the address was not
previously known, the status is changed to UNVERIFIED. The host MAY previously known, the status is changed to UNVERIFIED. The host MAY
choose to associate this address with one or more SAs. The choose to associate this address with one or more SAs. The
association with different SAs is a local policy decision, unless the association with different SAs is a local policy decision, unless the
peer has indicated that the address is Preferred, in which case the peer has indicated that the address is Preferred, in which case the
address should be put into use on a SA that is prioritized in the address should be put into use on a SA that is prioritized in the
security policy database. security policy database.
skipping to change at page 18, line 44 skipping to change at page 18, line 52
This document extends the scope of host mobility solutions defined in This document extends the scope of host mobility solutions defined in
[I-D.ietf-hip-rfc5206-bis] to include also host multihoming, and as a [I-D.ietf-hip-rfc5206-bis] to include also host multihoming, and as a
result, many of the same security considerations for mobility also result, many of the same security considerations for mobility also
pertain to multihoming. In particular, [I-D.ietf-hip-rfc5206-bis] pertain to multihoming. In particular, [I-D.ietf-hip-rfc5206-bis]
describes how HIP host mobility is resistant to different types of describes how HIP host mobility is resistant to different types of
impersonation attacks and DoS attacks. impersonation attacks and DoS attacks.
The security considerations for this document are similar to those of The security considerations for this document are similar to those of
[I-D.ietf-hip-rfc5206-bis] because the strong authentication [I-D.ietf-hip-rfc5206-bis] because the strong authentication
capabilities for mobility also carry over to mobility. [RFC4218] capabilities for mobility also carry over to end-host multihoming.
provides a threat analysis for IPv6 multihoming, and the remainder of
this section describes how HIP host multihoming addresses those
threats.
The high-level threats discussed in [RFC4218] involves redirection [RFC4218] provides a threat analysis for IPv6 multihoming, and the
remainder of this section describes how HIP host multihoming
addresses those threats.
The high-level threats discussed in [RFC4218] involve redirection
attacks for the purposes of packet recording, data manipulation, and attacks for the purposes of packet recording, data manipulation, and
availability. There are a few types of attackers to consider: on- availability. There are a few types of attackers to consider: on-
path attackers, off-path attackers, and malicious hosts. path attackers, off-path attackers, and malicious hosts.
[RFC4218] also makes the comment that in identifier/locator split [RFC4218] also makes the comment that in identifier/locator split
solutions such as HIP, application security mechanisms should be tied solutions such as HIP, application security mechanisms should be tied
to the identifier, not the locator, and attacks on the identifier to the identifier, not the locator, and attacks on the identifier
mechanism and on the mechanism binding locators to the identifier are mechanism and on the mechanism binding locators to the identifier are
of concern. This document does not consider the former issue of concern. This document does not consider the former issue
(application layer security bindings) to be within scope. The latter (application layer security bindings) to be within scope. The latter
skipping to change at page 21, line 11 skipping to change at page 21, line 22
the Host Identity Protocol (HIP)", RFC 7402, the Host Identity Protocol (HIP)", RFC 7402,
DOI 10.17487/RFC7402, April 2015, DOI 10.17487/RFC7402, April 2015,
<http://www.rfc-editor.org/info/rfc7402>. <http://www.rfc-editor.org/info/rfc7402>.
9.2. Informative references 9.2. Informative references
[RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 [RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6
Multihoming Solutions", RFC 4218, DOI 10.17487/RFC4218, Multihoming Solutions", RFC 4218, DOI 10.17487/RFC4218,
October 2005, <http://www.rfc-editor.org/info/rfc4218>. October 2005, <http://www.rfc-editor.org/info/rfc4218>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<http://www.rfc-editor.org/info/rfc4303>.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533,
June 2009, <http://www.rfc-editor.org/info/rfc5533>. June 2009, <http://www.rfc-editor.org/info/rfc5533>.
Appendix A. Document Revision History Appendix A. Document Revision History
To be removed upon publication To be removed upon publication
+----------+--------------------------------------------------------+ +----------+--------------------------------------------------------+
| Revision | Comments | | Revision | Comments |
skipping to change at page 22, line 49 skipping to change at page 22, line 49
| | issue 7: Clarify and distinguish between load | | | issue 7: Clarify and distinguish between load |
| | balancing and fault tolerance use cases. | | | balancing and fault tolerance use cases. |
| | | | | |
| draft-09 | Update author affiliations, IPR boilerplate to | | draft-09 | Update author affiliations, IPR boilerplate to |
| | trust200902, and one stale reference. | | | trust200902, and one stale reference. |
| | | | | |
| draft-10 | Improve security considerations section by reviewing | | draft-10 | Improve security considerations section by reviewing |
| | RFC 4218. | | | RFC 4218. |
| | | | | |
| | Clarified comment about applicability of shim6. | | | Clarified comment about applicability of shim6. |
| | |
| draft-11 | Editorial improvements based on last call comments. |
+----------+--------------------------------------------------------+ +----------+--------------------------------------------------------+
Authors' Addresses Authors' Addresses
Thomas R. Henderson (editor) Thomas R. Henderson (editor)
University of Washington University of Washington
Campus Box 352500 Campus Box 352500
Seattle, WA Seattle, WA
USA USA
 End of changes. 18 change blocks. 
36 lines changed or deleted 50 lines changed or added

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