draft-ietf-6man-multi-homed-host-06.txt   draft-ietf-6man-multi-homed-host-07.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: August 25, 2016 February 22, 2016 Expires: December 25, 2016 June 23, 2016
Routing packets from hosts in a multi-prefix network Routing packets from hosts in a multi-prefix network
draft-ietf-6man-multi-homed-host-06 draft-ietf-6man-multi-homed-host-07
Abstract Abstract
This document describes expected IPv6 host behavior in a network that This document describes expected IPv6 host behavior in a scenario
has more than one prefix, each allocated by an upstream network that that has more than one prefix, each allocated by an upstream network
implements BCP 38 ingress filtering, when the host has multiple that 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. This host behavior may interact with source address filters. This host behavior may interact with source address
selection in a given implementation, but logically follows it. Given selection in a given implementation, but logically follows it. Given
that the network or host is, or appears to be, multihomed with that the network or host is, or appears to be, multihomed with
multiple provider-allocated addresses, that the host has elected to multiple provider-allocated addresses, that the host has elected to
use a source address in a given prefix, and that some but not all use a source address in a given prefix, and that some but not all
neighboring routers are advertising that prefix in their Router neighboring routers are advertising that prefix in their Router
Advertisement Prefix Information Options, this document specifies to Advertisement Prefix Information Options, this document specifies to
which router a host should present its transmission. It updates RFC which router a host should present its transmission. It updates RFC
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 August 25, 2016. This Internet-Draft will expire on December 25, 2016.
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 31 skipping to change at page 2, line 31
1. Introduction and Applicability . . . . . . . . . . . . . . . 2 1. Introduction and Applicability . . . . . . . . . . . . . . . 2
1.1. Host Model . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Host Model . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Sending context expected by the host . . . . . . . . . . . . 5 2. Sending context expected by the host . . . . . . . . . . . . 5
2.1. Expectations the host has of the network . . . . . . . . 5 2.1. Expectations the host has of the network . . . . . . . . 5
2.2. Expectations of multihomed networks . . . . . . . . . . . 7 2.2. Expectations of multihomed networks . . . . . . . . . . . 7
3. Reasonable expectations of the host . . . . . . . . . . . . . 7 3. Reasonable expectations of the host . . . . . . . . . . . . . 7
3.1. Interpreting Router Advertisements . . . . . . . . . . . 7 3.1. Interpreting Router Advertisements . . . . . . . . . . . 7
3.2. Default Router Selection . . . . . . . . . . . . . . . . 8 3.2. Default Router Selection . . . . . . . . . . . . . . . . 8
3.3. Source Address Selection . . . . . . . . . . . . . . . . 8 3.3. Source Address Selection . . . . . . . . . . . . . . . . 9
3.4. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 9 3.4. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 9
3.5. History . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.5. History . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Residual issues . . . . . . . . . . . . . . . . . . . . . . . 9 4. Residual issues . . . . . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Change Log (RFC Editor: please delete) . . . . . . . 12 Appendix A. Change Log (RFC Editor: please delete) . . . . . . . 12
skipping to change at page 3, line 42 skipping to change at page 3, line 42
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. Host Model 1.1. Host Model
It could be argued that the proposal of this document, which is to 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 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 that advertised the prefix in its Router Advertisement (RA), is a
ES (e.g. Host) Model, discussed in section 3.3.4.2 of that document. form of [RFC1122]'s Strong End System (ES, e.g. Host) Model,
In short, [RFC1122] identifies two basic models, in which the "strong discussed in section 3.3.4.2 of that document. In short, [RFC1122]
host" model models the host as a set of hosts in one chassis, each of identifies two basic models, in which the "strong host" model models
which uses a single address on a single interface, and always both the host as a set of hosts in one chassis, each of which uses a
sends and receives on that interface, and the "weak host" model single address on a single interface, and always both sends and
treats the host as one system with zero or more addresses on every receives on that interface, and the "weak host" model treats the host
interface, and capable of using any interface for any communication. as one system with zero or more addresses on every interface, and
As noted there, neither model is completely satisfactory. For capable of using any interface for any communication. As noted
example, a host with a link-local-only interface and a default route there, neither model is completely satisfactory. For example, a host
pointing to the interface will necessarily send packets using any with a link-local-only interface and a default route pointing to that
address using that interface, and therefore be a de facto weak host. interface will necessarily send packets using that interface but with
If the router upstream from such a host implements BCP 38 Ingress a source address derived from some other interface, and will
Filtering [RFC2827], such as by implementing uRPF on each interface, therefore be a de facto weak host. If the router upstream from such
the router might prevent communication by weak hosts. a host implements BCP 38 Ingress Filtering [RFC2827], such as by
implementing uRPF on each interface, the router might prevent
communication by weak hosts.
+-----------------+ +-----------------+
| | | |
| MIF Router +---/--- other interfaces | MIF Router +---/--- other interfaces
| | | |
+---+---------+---+ +---+---------+---+
| | Two interfaces sharing a prefix | | Two interfaces sharing a prefix
--+-+-- --+-+-- --+-+-- --+-+--
| | | |
+--+---------+--+ +--+---------+--+
skipping to change at page 4, line 34 skipping to change at page 4, line 36
The proposal also differs slightly from [RFC1122]'s language of the The proposal also differs slightly from [RFC1122]'s language of the
Strong Host Model. The statement is that the packet will go to 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 router that advertised a given prefix, but doesn't state what
interface that might happen on. Hence, if the router is a multi- interface that might happen on. Hence, if the router is a multi-
interface (MIF) router and is using the same prefix on two or more interface (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 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 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 stated in those terms, but in terms of the interface used, and would
find a MIF router quite confusing: find a MIF router quite confusing:
(A) A host [MUST] silently discard an incoming datagram whose (A) A host MUST silently discard an incoming datagram whose
destination address does not correspond to the physical interface destination address does not correspond to the physical interface
through which it is received. through which it is received.
(B) A host [MUST] restrict itself to sending (non-source- routed) (B) A host MUST restrict itself to sending (non-source- routed) IP
IP datagrams only through the physical interface that corresponds datagrams only through the physical interface that corresponds to
to the IP source address of the datagrams. the IP source address of the datagrams.
However, comparing the presumptive route lookup mechanisms in each However, comparing the presumptive route lookup mechanisms in each
model, this proposal is indeed most similar to the Strong Host Model, model, this proposal is indeed most similar to the Strong Host Model,
as is any source/destination routing paradigm. as is any source/destination routing paradigm.
Strong: route(src IP addr, dest IP addr, TOS) -> gateway Strong: route(src IP addr, dest IP addr, TOS) -> gateway
Weak: route(dest IP addr, TOS) -> gateway, interface Weak: route(dest IP addr, TOS) -> gateway, interface
In the hypothetical MIF model suggested in Figure 1, the address In the hypothetical MIF model suggested in Figure 1, the address
fails to identify a single interface, but it does identify a single fails to identify a single interface, but it does identify a single
skipping to change at page 7, line 48 skipping to change at page 7, line 48
| | / | | | | | / | | |
| Alice +--/--( The Internet ) | Bob | | Alice +--/--( The Internet ) | Bob |
| | \ | | | | | \ | | |
+-------+ \ +---------+ +--+ | +-------+ \ +---------+ +--+ |
( ISP B ) - + Bob-B +--+ +-----+ ( ISP B ) - + Bob-B +--+ +-----+
+---------+ | +---------+ |
Figure 3: PIOs, RIOs, and Default Routes Figure 3: PIOs, RIOs, and Default Routes
The implications bear consideration. Imagine, Figure 3, that hosts The implications bear consideration. Imagine, Figure 3, that hosts
Alice and Bob are in communication, Bob's network is multihomed, and Alice and Bob are in communication. Bob's network consists at least
Bob's first hop routers are Bob-A (to upstream ISP A advertising of Bob (the computer), 2 routers (Bob-A and Bob-B), and the links
prefix PA) and Bob-B (to upstream network B and advertising prefix between them; it may be much larger, for example a campus or
PB). If Bob is responding to a message from Alice, his choice of corporate network. Bob's network is therefore multihomed, and Bob's
source address is forced to be the address Alice used as a first hop routers are Bob-A (to upstream ISP A advertising prefix PA)
destination (which we may presume to have been in prefix PA). Hence, and Bob-B (to upstream network B and advertising prefix PB). If Bob
Bob created or was assigned an address in PA, and can only reasonably is responding to a message from Alice, his choice of source address
send traffic using it to Bob-A as a first hop router. If there were is forced to be the address Alice used as a destination (which we may
several instances of Bob-A and one had advertised itself as a default presume to have been in prefix PA). Hence, Bob created or was
router or as having a route to Alice, that is the router Bob should assigned an address in PA, and can only reasonably send traffic using
choose. If none of Bob-A have advertised that but Bob-B has, it is it to Bob-A as a first hop router. If there were several instances
irrelevant; Bob is using the address allocated in PA and courts a BCP of Bob-A and one had advertised itself as a default router or as
38 discard if he doesn't send the packet to Bob-A. 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 PA 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 In the special case that Bob is initiating the conversation, an RIO
might, however, influence source address choice. Bob could might, however, influence source address choice. Bob could
presumably use any address allocated to him, in this case his address presumably use any address allocated to him, in this case his address
in PA or PB. If Bob-B has advertised an RIO for Alice's prefix and in PA or PB. 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 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 selection - choosing an address that would allow him to make use of
the RIO. the RIO.
3.2. Default Router Selection 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. (If no router has advertised the prefix in an RA, normal
routing metrics will apply. An example is a host connected to the
Internet via one router, and at the same time connected by a VPN to a
private domain which is also connected to the global Internet.)
As a result of doing so, when a host sends a packet using a source As a result of this, 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
"simplest" network described in Section 2.1, that would get it to the "simplest" network described in Section 2.1, that would get it to the
only router that is directly capable of getting it to the right ISP. only router that is directly capable of getting it to the right ISP.
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.
skipping to change at page 9, line 45 skipping to change at page 10, line 6
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 2, which happens to be one of the authors' home plus corporate Figure 2, for example a home plus corporate home-office
home-office configuration, the two upstream routers might be on configuration, the two upstream routers might be on different LANs
different LANs and therefore different subnets (e.g., the host is and therefore different subnets (e.g., the host is itself multi-
itself multi-homed). In that case, there is no way for the "wrong" homed). In that case, there is no way for the "wrong" router to
router to detect the existence of the "right" router, or to route 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.
5. IANA Considerations 5. IANA Considerations
This memo asks the IANA for no new parameters. This memo asks the IANA for no new parameters.
6. Security Considerations 6. Security Considerations
skipping to change at page 10, line 29 skipping to change at page 10, line 36
There might be a small privacy improvement, however: with the current There might be a small privacy improvement, however: with the current
practice, a multihomed host that sends packets with the wrong address practice, a multihomed host that sends packets with the wrong address
to an upstream router or network discloses the prefix of one upstream to an upstream router or network discloses the prefix of one upstream
to the other upstream network. This practice reduces the probability to the other upstream network. This practice reduces the probability
of that occurrence. of that occurrence.
7. Acknowledgements 7. Acknowledgements
Comments were received from Jinmei Tatuya and Ole Troan, who have Comments were received from Jinmei Tatuya and Ole Troan, who have
suggested important text, plus Mikael Abrahamsson, Steven Barth, suggested important text, plus Mikael Abrahamsson, Steven Barth,
Juliusz Chroboczek, Toerless Eckert, David Farmer, Dusan Mudric, Carlos Bernardos Cano, Zhen Cao, Juliusz Chroboczek, Toerless Eckert,
Tadahisa Okimoto, Pierre Pfister, Behcet Sarikaya, Mark Smith, Bob David Farmer, Dusan Mudric, Tadahisa Okimoto, Pierre Pfister, Behcet
Hinden, and James Woodyatt. Sarikaya, Mark Smith, Bob Hinden, and James Woodyatt.
8. References 8. References
8.1. Normative References 8.1. Normative References
[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, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
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 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
November 2005, <http://www.rfc-editor.org/info/rfc4191>. November 2005, <http://www.rfc-editor.org/info/rfc4191>.
skipping to change at page 11, line 18 skipping to change at page 11, line 22
<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
[I-D.ietf-rtgwg-dst-src-routing] [I-D.ietf-rtgwg-dst-src-routing]
Lamparter, D., "Destination/Source Routing", draft-ietf- Lamparter, D. and A. Smirnov, "Destination/Source
rtgwg-dst-src-routing-00 (work in progress), October 2015. Routing", draft-ietf-rtgwg-dst-src-routing-02 (work in
progress), May 2016.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, DOI 10.17487/ Communication Layers", STD 3, RFC 1122,
RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<http://www.rfc-editor.org/info/rfc1122>. <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>.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
2004, <http://www.rfc-editor.org/info/rfc3704>. 2004, <http://www.rfc-editor.org/info/rfc3704>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, DOI 10.17487/ Address Autoconfiguration", RFC 4862,
RFC4862, September 2007, DOI 10.17487/RFC4862, September 2007,
<http://www.rfc-editor.org/info/rfc4862>. <http://www.rfc-editor.org/info/rfc4862>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<http://www.rfc-editor.org/info/rfc4941>. <http://www.rfc-editor.org/info/rfc4941>.
[RFC6092] Woodyatt, J., Ed., "Recommended Simple Security [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security
Capabilities in Customer Premises Equipment (CPE) for Capabilities in Customer Premises Equipment (CPE) for
Providing Residential IPv6 Internet Service", RFC 6092, Providing Residential IPv6 Internet Service", RFC 6092,
skipping to change at page 12, line 23 skipping to change at page 12, line 28
DOI 10.17487/RFC7084, November 2013, DOI 10.17487/RFC7084, November 2013,
<http://www.rfc-editor.org/info/rfc7084>. <http://www.rfc-editor.org/info/rfc7084>.
[RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., [RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T.,
and D. Wing, "IPv6 Multihoming without Network Address and D. Wing, "IPv6 Multihoming without Network Address
Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014, Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014,
<http://www.rfc-editor.org/info/rfc7157>. <http://www.rfc-editor.org/info/rfc7157>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/ Autoconfiguration (SLAAC)", RFC 7217,
RFC7217, April 2014, DOI 10.17487/RFC7217, April 2014,
<http://www.rfc-editor.org/info/rfc7217>. <http://www.rfc-editor.org/info/rfc7217>.
Appendix A. Change Log (RFC Editor: please delete) Appendix A. Change Log (RFC Editor: please delete)
Initial Version: 2015-08-05 Initial Version: 2015-08-05
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.
skipping to change at page 13, line 7 skipping to change at page 13, line 13
* Some wording errors. * Some wording errors.
* Requests for discussion of the handling of the RIO, PIO, and * Requests for discussion of the handling of the RIO, PIO, and
Default Router List in an RA. Default Router List in an RA.
WG Versions 00-02: More clarifications after more WG discussions, WG Versions 00-02: More clarifications after more WG discussions,
2015-11-03. 2015-11-03.
WG Version 03: A final clarification re uRPF, 2015-12-15. WG Version 03: A final clarification re uRPF, 2015-12-15.
WG Versions 04-07: Various clarifications and review comments,
2016-06-23.
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. 19 change blocks. 
60 lines changed or deleted 71 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/