draft-ietf-6man-multi-homed-host-00.txt   draft-ietf-6man-multi-homed-host-01.txt 
IPv6 Maintenance F. Baker IPv6 Maintenance F. Baker
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Updates: 4861 (if approved) B. Carpenter Updates: 4861 (if approved) B. Carpenter
Intended status: Standards Track Univ. of Auckland Intended status: Standards Track Univ. of Auckland
Expires: April 17, 2016 October 15, 2015 Expires: April 17, 2016 October 15, 2015
Host routing in a multi-prefix network Routing packets from hosts in a multi-prefix network
draft-ietf-6man-multi-homed-host-00 draft-ietf-6man-multi-homed-host-01
Abstract Abstract
This note describes expected IPv6 host behavior in a network that has This document describes expected IPv6 host behavior in a network that
more than one prefix, each allocated by an upstream network that has more than one prefix, each allocated by an upstream network that
implements BCP 38 ingress filtering, when the host has multiple implements BCP 38 ingress filtering, when the host has multiple
routers to choose from. It also applies to other scenarios such as routers to choose from. It also applies to other scenarios such as
the usage of stateful firewalls that effectively act as address-based the usage of stateful firewalls that effectively act as address-based
filters. filters.
This host behavior may interact with source address selection in a This host behavior may interact with source address selection in a
given implementation, but logically follows it. Given that the given implementation, but logically follows it. Given that the
network or host is, or appears to be, multihomed with multiple network or host is, or appears to be, multihomed with multiple
provider-allocated addresses, that the host has elected to use a provider-allocated addresses, that the host has elected to use a
source address in a given prefix, and that some but not all source address in a given prefix, and that some but not all
skipping to change at page 2, line 23 skipping to change at page 2, line 23
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction and Applicability . . . . . . . . . . . . . . . 2 1. Introduction and Applicability . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Host Model . . . . . . . . . . . . . . . . . . . . . . . 3
2. Sending context expected by the host . . . . . . . . . . . . 3 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
2.1. Expectations the host has of the network . . . . . . . . 3 2. Sending context expected by the host . . . . . . . . . . . . 5
2.2. Expectations of multihomed networks . . . . . . . . . . . 5 2.1. Expectations the host has of the network . . . . . . . . 5
3. Reasonable expectations of the host . . . . . . . . . . . . . 5 2.2. Expectations of multihomed networks . . . . . . . . . . . 7
3.1. Default Router Selection . . . . . . . . . . . . . . . . 5 3. Reasonable expectations of the host . . . . . . . . . . . . . 7
3.2. Source Address Selection . . . . . . . . . . . . . . . . 5 3.1. Interpreting Router Advertisements . . . . . . . . . . . 7
3.3. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Default Router Selection . . . . . . . . . . . . . . . . 8
3.4. History . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Source Address Selection . . . . . . . . . . . . . . . . 8
4. Residual issues . . . . . . . . . . . . . . . . . . . . . . . 6 3.4. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 3.5. History . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4. Residual issues . . . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction and Applicability 1. Introduction and Applicability
This note describes the expected behavior of an IPv6 [RFC2460] host This document describes the expected behavior of an IPv6 [RFC2460]
in a network that has more than one prefix, each allocated by an host in a network that has more than one prefix, each allocated by an
upstream network that implements BCP 38 [RFC2827] ingress filtering, upstream network that implements BCP 38 [RFC2827] ingress filtering,
and in which the host is presented with a choice of routers. It and in which the host is presented with a choice of routers. It
expects that the network will implement some form of egress routing, expects that the network will implement some form of egress routing,
so that packets sent to a host outside the local network from a given so that packets sent to a host outside the local network from a given
ISP's prefix will go to that ISP. If the packet is sent to the wrong ISP's prefix will go to that ISP. If the packet is sent to the wrong
egress, it is liable to be discarded by the BCP 38 filter. However, egress, it is liable to be discarded by the BCP 38 filter. However,
the mechanics of egress routing once the packet leaves the host are the mechanics of egress routing once the packet leaves the host are
out of scope. The question here is how the host interacts with that out of scope. The question here is how the host interacts with that
network. network.
BCP 38 filtering by ISPs is not the only scenario where such behavior BCP 38 filtering by ISPs is not the only scenario where such behavior
is valuable. The combination of existing recommendations for home is valuable. Implementations that combine existing recommendations,
gateways [RFC6092] [RFC7084] can also result in such filtering. such as [RFC6092] [RFC7084] can also result in such filtering.
Another case is when the connections to the upstream networks include Another case is when the connections to the upstream networks include
stateful firewalls, such that return packets in a stream will be stateful firewalls, such that return packets in a stream will be
discarded if they do not return via the firewall that created state discarded if they do not return via the firewall that created state
for the outgoing packets. A similar cause of such discards is for the outgoing packets. A similar cause of such discards is
unicast reverse path forwarding (uRPF) [RFC3704]. unicast reverse path forwarding (uRPF) [RFC3704].
In this document, the term "filter" is used for simplicity to cover In this document, the term "filter" is used for simplicity to cover
all such cases. In any case, one cannot assume the host to be aware all such cases. In any case, one cannot assume the host to be aware
whether an ingress filter, a stateful firewall, or any other type of whether an ingress filter, a stateful firewall, or any other type of
filter is in place. Therefore, the only safe solution is to filter is in place. Therefore, the only consistent solution is to
implement the features defined in this document. implement the features defined in this document.
Note that, apart from ensuring that a message with a given source Note that, apart from ensuring that a message with a given source
address is given to a first-hop router that appears to know about the address is given to a first-hop router that appears to know about the
prefix in question, this specification is consistent with [RFC4861]. prefix in question, this specification is consistent with [RFC4861].
Nevertheless, implementers of Sections 5.2, 6.2.3, 6.3.4 and 8 of RFC Nevertheless, implementers of Sections 5.2, 6.2.3, 6.3.4 and 8 of RFC
4861 will need to extend their implementations accordingly. This 4861 will need to extend their implementations accordingly. This
specification is fully consistent with [RFC6724] and implementers specification is fully consistent with [RFC6724] and implementers
will need to add support for its Rule 5.5. Hosts that do not support will need to add support for its Rule 5.5. Hosts that do not support
these features may fail to communicate in the presence of filters as these features may fail to communicate in the presence of filters as
described above. described above.
1.1. Requirements Language 1.1. Host Model
It could be argued that the proposal of this document, which is to
send messages using a source address in a given prefix to the router
that advertised the prefix in its RA, is a form of [RFC1122]'s Strong
ES (e.g. Host) Model, discussed in section 3.3.4.2 of that document.
In short, [RFC1122] identifies two basic models, in which the "strong
host" model models the host as a set of hosts in one chassis, each of
which uses a single address on a single interface, and always both
sends and receives on that interface, and the "weak host" model
treats the host as one system with zero or more addresses on every
interface, and capable of using any interface for any communication.
As noted there, neither model is completely satisfactory. For
example, a host with an addressless interface and a default route
pointing to the interface will necessarily send packets using any
address using that interface, and therefore be a de facto weak host.
However, if the router upstream from the host implements BCP 38
Ingress Filtering [RFC2827], such as by implementing uRPF on each
interface, the router is configured to only permit communication by
strong hosts.
+-----------------+
| |
| MIF Router +---/--- other interfaces
| |
+---+---------+---+
| | Two interfaces sharing a prefix
--+-+-- --+-+--
| |
+--+---------+--+
| MIF Host |
+---------------+
Figure 1: Hypothetical MIF interconnection
The proposal also differs slightly from [RFC1122]'s language of the
Strong Host Model. The statement is that the packet will go to the
router that advertised a given prefix, but doesn't state what
interface that might happen on. Hence, if the router is a MIF router
and is using the same prefix on two or more LANs shared by the host
(as in Figure 1), the host might use each of those LANs and meet the
requirement. The Strong Host Model is not stated in those terms, but
in terms of the interface used, and would find a MIF router quite
confusing:
(A) A host [MUST] silently discard an incoming datagram whose
destination address does not correspond to the physical interface
through which it is received.
(B) A host [MUST] restrict itself to sending (non-source- routed)
IP datagrams only through the physical interface that corresponds
to the IP source address of the datagrams.
However, comparing the presumptive route lookup mechanisms in each
model, this proposal is indeed most similar to the Strong Host Model,
as is any source/destination routing paradigm.
Strong: route(src IP addr, dest IP addr, TOS) -> gateway
Weak: route(dest IP addr, TOS) -> gateway, interface
In the hypothetical MIF model suggested in Figure 1, the address
fails to identify a single interface, but it does identify a single
gateway.
1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Sending context expected by the host 2. Sending context expected by the host
2.1. Expectations the host has of the network 2.1. Expectations the host has of the network
A host receives prefixes in a Router Advertisement [RFC4861], which A host receives prefixes in a Router Advertisement [RFC4861], which
skipping to change at page 4, line 35 skipping to change at page 6, line 22
+----+----+ +----+----+ +----+----+ +----+----+ +----+----+ +----+----+ +----+----+ +----+----+
| | | | | | | |
+------+------+ | +--------+ | +------+------+ | +--------+ |
| +--+ Host +--+ | +--+ Host +--+
+----+----+ +--------+ +----+----+ +--------+
| Host | | Host |
+---------+ +---------+
Common LAN Case Disjoint LAN Case Common LAN Case Disjoint LAN Case
(Multihomed Network) (Multihomed Host) (Multihomed Network) (Multihomed Host)
Figure 1: Two simple networks Figure 2: Two simple networks
If there is no routing protocol among those routers, there is no If there is no routing protocol among those routers, there is no
mechanism by which packets can be deterministically forwarded between mechanism by which packets can be deterministically forwarded between
the routers (as described in BCP 84 [RFC3704]) in order to avoid the routers (as described in BCP 84 [RFC3704]) in order to avoid
filters. Even if there was routing, it would result in an indirect filters. Even if there was routing, it would result in an indirect
route, rather than a direct route originating with the host; this is route, rather than a direct route originating with the host; this is
not "wrong", but can be inefficient. Therefore the host would do not "wrong", but can be inefficient. Therefore the host would do
well to select the appropriate router itself. well to select the appropriate router itself.
Since the host derives fundamental default routing information from Since the host derives fundamental default routing information from
skipping to change at page 5, line 18 skipping to change at page 7, line 7
a PIO has not previously been common, and it is possible that a PIO has not previously been common, and it is possible that
existing host implementations simply ignore such a PIO or that a existing host implementations simply ignore such a PIO or that a
router implementation rejects such a PIO as a configuration error. router implementation rejects such a PIO as a configuration error.
Newer implementations that support this mechanism will need to be Newer implementations that support this mechanism will need to be
updated accordingly: a host SHOULD NOT ignore a PIO simply because updated accordingly: a host SHOULD NOT ignore a PIO simply because
both L and A flags are cleared; a router SHOULD be able to send such both L and A flags are cleared; a router SHOULD be able to send such
a PIO. a PIO.
2.2. Expectations of multihomed networks 2.2. Expectations of multihomed networks
The direct implication of Section 2.1 is that routing protocols used The direct implication of Section 2.1 is that, if the network uses a
in multihomed networks SHOULD be capable of source-prefix based routing protocol, the routing protocols used in multihomed networks
egress routing, and that multihomed networks SHOULD deploy them. SHOULD implement source-prefix based egress routing. Network designs
exist that can usefully limit themselves to static routing (such a a
simple tree network), or may internally use no routers at all, such
as a single LAN with two CE routers, each of which leads to a
different upstream network.
3. Reasonable expectations of the host 3. Reasonable expectations of the host
3.1. Default Router Selection 3.1. Interpreting Router Advertisements
As described in [RFC4191] and [RFC4861], a Router Advertisement may
contain zero or more Prefix information Options (PIOs), zero or more
Route Information Options (RIOs), or a Default Router List. In their
original intent, these indicate general information to a host: "these
are your default routers", "you might create or be configured with an
address in this prefix", or "this router would be a good place to
send traffic directed to a given destination prefix". In a multi-
homed network implementing source/destination routing, the
interpretation of a default router list or an RIO has to be modified
with the words "if the source address is in one of the prefixes I
advertise in a PIO". Additionally, the PIO must be reinterpreted to
also imply that the advertising router would be a reasonable first
hop for any packet using a source address in any advertised prefix.
+---------+ |
( ISP A ) - + Bob-A +--+ +-----+
+---------+ / +---------+ +--+ |
| | / | | |
| Alice +---/---( The Internet ) | Bob |
| | \ | | |
+---------+ \ +---------+ +--+ |
( ISP B ) - + Bob-B +--+ +-----+
+---------+ |
Figure 3: PIOs, RIOs, and Default Routes
The implications bear consideration. Imagine, Figure 3, that hosts
Alice and Bob are in communication, Bob's network is multihomed, and
Bob's first hop routers are Bob-A (to upstream ISP A advertising
prefix A') and Bob-B (to upstream network B and advertising prefix
B'). If Bob is responding to a message from Alice, his choice of
source address is forced to be the address Alice used as a
destination (which we may presume to have been in prefix A'). Hence,
Bob created or was assigned an address in A', and can only reasonably
send traffic using it to Bob-A as a first hop router. If there were
several instances of Bob-A and one had advertised itself as a default
router or as having a route to Alice, that is the router Bob should
choose. If none of Bob-A have advertised that but Bob-B has, it is
irrelevant; Bob is using the address allocated in A' and courts a BCP
38 discard if he doesn't send the packet to Bob-A.
In the special case that Bob is initiating the conversation, an RIO
might, however, influence source address choice. Bob could
presumably use any address allocated to him, in this case his address
in A' or B'. If Bob-B has advertised an RIO for Alice's prefix and
Bob-A has not, Bob MAY take that fact into account in address
selection - choosing an address that would allow him to make use of
the RIO.
3.2. Default Router Selection
Default Router Selection is modified as follows: A host SHOULD select Default Router Selection is modified as follows: A host SHOULD select
default routers for each prefix it is assigned an address in. default routers for each prefix it is assigned an address in.
Routers that have advertised the prefix in its Router Advertisement Routers that have advertised the prefix in its Router Advertisement
message SHOULD be preferred over routers that do not advertise the message SHOULD be preferred over routers that do not advertise the
prefix. prefix.
As a result of doing so, when a host sends a packet using a source As a result of doing so, when a host sends a packet using a source
address in one of those prefixes and has no history directing it address in one of those prefixes and has no history directing it
otherwise, it SHOULD send it to the indicated default router. In the otherwise, it SHOULD send it to the indicated default router. In the
skipping to change at page 5, line 47 skipping to change at page 8, line 44
This will also apply in more complex networks, even when more than This will also apply in more complex networks, even when more than
one physical or virtual interface is involved. one physical or virtual interface is involved.
In more complex cases, wherein routers advertise RAs for multiple In more complex cases, wherein routers advertise RAs for multiple
prefixes whether or not they have direct or isolated upstream prefixes whether or not they have direct or isolated upstream
connectivity, the host is dependent on the routing system already. connectivity, the host is dependent on the routing system already.
If the host gives the packet to a router advertising its source If the host gives the packet to a router advertising its source
prefix, it should be able to depend on the router to do the right prefix, it should be able to depend on the router to do the right
thing. thing.
3.2. Source Address Selection 3.3. Source Address Selection
There is an interaction with Default Address Selection [RFC6724]. There is an interaction with Default Address Selection [RFC6724].
Rule 5.5 of that specification states that the source address used to Rule 5.5 of that specification states that the source address used to
send to a given destination address should if possible be chosen from send to a given destination address should if possible be chosen from
a prefix known to be advertised by the first-hop router for that a prefix known to be advertised by the first-hop router for that
destination. This selection rule would be applicable in a host destination. This selection rule would be applicable in a host
following the recommendation in the previous paragraph. following the recommendation in the previous section.
3.3. Redirects 3.4. Redirects
There is potential for adverse interaction with any off-link Redirect There is potential for adverse interaction with any off-link Redirect
(Redirect for a GUA destination that is not on-link) message sent by (Redirect for a GUA destination that is not on-link) message sent by
a router in accordance with Section 8 of [RFC4861]. Hosts SHOULD a router in accordance with Section 8 of [RFC4861]. Hosts SHOULD
apply off-link redirects only for the specific pair of source and apply off-link redirects only for the specific pair of source and
destination addresses concerned, so the host's Destination Cache may destination addresses concerned, so the host's Destination Cache may
need to contain appropriate source-specific entries. need to contain appropriate source-specific entries.
3.4. History 3.5. History
Some modern hosts maintain history, in terms of what has previously Some modern hosts maintain history, in terms of what has previously
worked or not worked for a given address or prefix and in some cases worked or not worked for a given address or prefix and in some cases
the effective window and MSS values for TCP or other protocols. This the effective window and MSS values for TCP or other protocols. This
might include a next hop address for use when a packet is sent to the might include a next hop address for use when a packet is sent to the
indicated address. indicated address.
When such a host makes a successful exchange with a remote When such a host makes a successful exchange with a remote
destination using a particular address pair, and the host has destination using a particular address pair, and the host has
previously received a PIO that matches the source address, then the previously received a PIO that matches the source address, then the
skipping to change at page 6, line 45 skipping to change at page 9, line 42
Consider a network where routers on a link run a routing protocol and Consider a network where routers on a link run a routing protocol and
are configured with the same information. Thus, on each link all are configured with the same information. Thus, on each link all
routers advertise all prefixes on the link. The assumption that routers advertise all prefixes on the link. The assumption that
packets will be forwarded to the appropriate egress by the local packets will be forwarded to the appropriate egress by the local
routing system might cause at least one extra hop in the local routing system might cause at least one extra hop in the local
network (from the host to the wrong router, and from there to another network (from the host to the wrong router, and from there to another
router on the same link). router on the same link).
In a slightly more complex situation such as the disjoint LAN case of In a slightly more complex situation such as the disjoint LAN case of
Figure 1, which happens to be one of the authors' home plus corporate Figure 2, which happens to be one of the authors' home plus corporate
home-office configuration, the two upstream routers might be on home-office configuration, the two upstream routers might be on
different LANs and therefore different subnets (e.g., the host is different LANs and therefore different subnets (e.g., the host is
itself multi-homed). In that case, there is no way for the "wrong" itself multi-homed). In that case, there is no way for the "wrong"
router to detect the existence of the "right" router, or to route to router to detect the existence of the "right" router, or to route to
it. it.
In such a case it is particularly important that hosts take the In such a case it is particularly important that hosts take the
responsibility to memorize and select the best first-hop as described responsibility to memorize and select the best first-hop as described
in Section 3. in Section 3.
skipping to change at page 7, line 45 skipping to change at page 10, line 41
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>. December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
November 2005, <http://www.rfc-editor.org/info/rfc4191>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, DOI 10.17487/RFC4861, September 2007,
<http://www.rfc-editor.org/info/rfc4861>. <http://www.rfc-editor.org/info/rfc4861>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<http://www.rfc-editor.org/info/rfc6724>. <http://www.rfc-editor.org/info/rfc6724>.
8.2. Informative References 8.2. Informative References
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<http://www.rfc-editor.org/info/rfc1122>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <http://www.rfc-editor.org/info/rfc2827>. May 2000, <http://www.rfc-editor.org/info/rfc2827>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>. 2003, <http://www.rfc-editor.org/info/rfc3315>.
skipping to change at page 9, line 18 skipping to change at page 12, line 24
Version 01: Update text on PIOs, added text on Redirects, and Version 01: Update text on PIOs, added text on Redirects, and
clarified the concept of a "simple" network, 2015-08-13. clarified the concept of a "simple" network, 2015-08-13.
Version 02: Clarifications after WG discussions, 2015-08-19. Version 02: Clarifications after WG discussions, 2015-08-19.
Version 03: More clarifications after more WG discussions, Version 03: More clarifications after more WG discussions,
especially adding stateful firewalls, uRPF, and more precise especially adding stateful firewalls, uRPF, and more precise
discussion of RFC 4861, 2015-09-03. discussion of RFC 4861, 2015-09-03.
Version 04: Responds to various comments including
* Questions regarding RFC 1122's strong and weak host models.
This model is, strictly speaking, neither, but is most similar
to the strong host model.
* Some wording errors.
* Requests for discussion of the handling of the RIO, PIO, and
Default Router List in an RA.
Authors' Addresses Authors' Addresses
Fred Baker Fred Baker
Cisco Systems Cisco Systems
Santa Barbara, California 93117 Santa Barbara, California 93117
USA USA
Email: fred@cisco.com Email: fred@cisco.com
Brian Carpenter Brian Carpenter
 End of changes. 18 change blocks. 
38 lines changed or deleted 180 lines changed or added

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