draft-ietf-v6ops-siit-dc-2xlat-01.txt   draft-ietf-v6ops-siit-dc-2xlat-02.txt 
IPv6 Operations T. Anderson IPv6 Operations T. Anderson
Internet-Draft Redpill Linpro Internet-Draft Redpill Linpro
Intended status: Informational S. Steffann Intended status: Informational S. Steffann
Expires: December 30, 2015 S.J.M. Steffann Consultancy Expires: April 14, 2016 S.J.M. Steffann Consultancy
June 28, 2015 October 12, 2015
SIIT-DC: Dual Translation Mode SIIT-DC: Dual Translation Mode
draft-ietf-v6ops-siit-dc-2xlat-01 draft-ietf-v6ops-siit-dc-2xlat-02
Abstract Abstract
This document describes an extension of the Stateless IP/ICMP This document describes an extension of the Stateless IP/ICMP
Translation for IPv6 Internet Data Centre Environments architecture Translation for IPv6 Internet Data Centre Environments architecture
(SIIT-DC), which allows applications, protocols, or nodes that are (SIIT-DC), which allows applications, protocols, or nodes that are
incompatible with IPv6, and/or Network Address Translation to operate incompatible with IPv6, and/or Network Address Translation to operate
correctly in an SIIT-DC environment. This is accomplished by correctly in an SIIT-DC environment. This is accomplished by
introducing a new component called an SIIT-DC Edge Relay, which introducing a new component called an SIIT-DC Edge Relay, which
reverses the translations made by an SIIT-DC Border Relay. The reverses the translations made by an SIIT-DC Border Relay. The
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 December 30, 2015. This Internet-Draft will expire on April 14, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 21 skipping to change at page 2, line 21
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Edge Relay Description . . . . . . . . . . . . . . . . . . . 4 3. Edge Relay Description . . . . . . . . . . . . . . . . . . . 4
3.1. Node-Based Edge Relay . . . . . . . . . . . . . . . . . . 5 3.1. Node-Based Edge Relay . . . . . . . . . . . . . . . . . . 5
3.2. Network-Based Edge Relay . . . . . . . . . . . . . . . . 6 3.2. Network-Based Edge Relay . . . . . . . . . . . . . . . . 7
3.2.1. Edge Router "On A Stick" . . . . . . . . . . . . . . 7 3.2.1. Edge Router "On A Stick" . . . . . . . . . . . . . . 8
3.2.2. Edge Router that Bridges IPv6 Packets . . . . . . . . 8 3.2.2. Edge Router that Bridges IPv6 Packets . . . . . . . . 9
4. Deployment Considerations . . . . . . . . . . . . . . . . . . 9 4. Deployment Considerations . . . . . . . . . . . . . . . . . . 9
4.1. IPv6 Path MTU . . . . . . . . . . . . . . . . . . . . . . 9 4.1. IPv6 Path MTU . . . . . . . . . . . . . . . . . . . . . . 9
4.2. IPv4 MTU . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. IPv4 MTU . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. IPv4 Identification Header . . . . . . . . . . . . . . . 10 4.3. IPv4 Identification Header . . . . . . . . . . . . . . . 10
5. Intra-IDC IPv4 Communication . . . . . . . . . . . . . . . . 10 5. Intra-IDC IPv4 Communication . . . . . . . . . . . . . . . . 10
5.1. Hairpinning by the SIIT-DC Border Relay . . . . . . . . . 10 5.1. Hairpinning by the SIIT-DC Border Relay . . . . . . . . . 10
5.2. Additional EAMs Configured in Edge Relay . . . . . . . . 11 5.2. Additional EAMs Configured in Edge Relay . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8.1. Address Spoofing . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Examples: Network-Based IPv4 Connectivity . . . . . 15 Appendix A. Examples: Network-Based IPv4 Connectivity . . . . . 15
A.1. Subnet with IPv4 Service Addresses . . . . . . . . . . . 15 A.1. Subnet with IPv4 Service Addresses . . . . . . . . . . . 16
A.2. Subnet with Unrouted IPv4 Addresses . . . . . . . . . . . 16 A.2. Subnet with Unrouted IPv4 Addresses . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
SIIT-DC [I-D.ietf-v6ops-siit-dc] describes an architecture where SIIT-DC [I-D.ietf-v6ops-siit-dc] describes an architecture where
IPv4-only users can access IPv6-only services through a stateless IPv4-only users can access IPv6-only services through a stateless
translator called an SIIT-DC Border Relay (BR). This approach has translator called an SIIT-DC Border Relay (BR). This approach has
certain limitations, however. In particular, the following cases certain limitations, however. In particular, the following cases
will work poorly or not at all: will work poorly or not at all:
skipping to change at page 3, line 32 skipping to change at page 3, line 32
translations and forward them to the IPv4 client. The node or translations and forward them to the IPv4 client. The node or
application is thus provided with "virtual" IPv4 Internet application is thus provided with "virtual" IPv4 Internet
connectivity that retains end-to-end transparency for the IPv4 connectivity that retains end-to-end transparency for the IPv4
addresses. addresses.
2. Terminology 2. Terminology
This document makes use of the following terms: This document makes use of the following terms:
SIIT-DC Border Relay (BR) SIIT-DC Border Relay (BR)
A device or a logical function that translates traffic between A device or a logical function that performs stateless protocol
IPv4 clients and IPv6 services. See [I-D.ietf-v6ops-siit-dc]. translation between IPv4 and IPv6. It MUST do so in accordance
with [RFC6145] and [I-D.ietf-v6ops-siit-eam].
SIIT-DC Edge Relay (ER) SIIT-DC Edge Relay (ER)
A device or logical function that provides "native" IPv4 A device or logical function that provides "native" IPv4
connectivity to IPv4-only nodes or applications. It functions in connectivity to IPv4-only devices or application software. It is
the same way as a BR, but is located close to the IPv4-only nodes/ very similar in function to a BR, but is typically located close
applications it is supporting rather than on the network border. to the IPv4-only component(s) it is supporting rather than on the
IDC's outer network border. An ER may be either Node-Based
(Section 3.1) or Network-Based (Section 3.2).
IPv4 Service Address IPv4 Service Address
An IPv4 address representing an IPv6 service, with which IPv4-only An IPv4 address representing a node or service located in an IPv6
clients communicates. It is coupled with an IPv6 Service Address network. It is coupled with an IPv6 Service Address using an EAM.
using an EAM. Packets sent to this address is translated to IPv6 Packets sent to this address is translated to IPv6 by the BR, and
by the BR and possibly back to IPv4 again by the ER, and vice possibly back to IPv4 by an ER, before reaching the node or
versa in the opposite direction. service.
IPv6 Service Address IPv6 Service Address
An IPv6 address assigned to an application, node, or service; An IPv6 address assigned to an application, node, or service;
either directly or indirectly (through an ER). It is coupled with either directly or indirectly (through an ER). It is coupled with
an IPv4 Service Address using an EAM. IPv4-only clients an IPv4 Service Address using an EAM. IPv4-only clients
communicates with the IPv6 Service Address through SIIT-DC. communicates with the IPv6 Service Address through SIIT-DC.
Explicit Address Mapping (EAM) Explicit Address Mapping (EAM)
A bi-directional coupling between an IPv4 Service Address and an A bi-directional coupling between an IPv4 Service Address and an
IPv6 Service Address configured in an BR/ER. When translating IPv6 Service Address configured in a BR or ER. When translating
between IPv4 and IPv6, the BR/ER changes the address fields in the between IPv4 and IPv6, the BR/ER changes the address fields in the
translated packet's IP header according to any matching EAM. The translated packet's IP header according to any matching EAM. The
EAM algorithm is specified in [I-D.ietf-v6ops-siit-eam]. EAM algorithm is specified in [I-D.ietf-v6ops-siit-eam].
Translation Prefix Translation Prefix
An IPv6 prefix into which the entire IPv4 address space is mapped, An IPv6 prefix into which the entire IPv4 address space is mapped,
according to the algorithm in [RFC6052]. The Translation Prefix according to the algorithm in [RFC6052]. The Translation Prefix
is routed to the BR's IPv6 interface. When translating between is routed to the BR's IPv6 interface. When translating between
IPv4 and IPv6, an BR/ER will insert/remove the Translation Prefix IPv4 and IPv6, an BR/ER will insert/remove the Translation Prefix
into/from the address fields in the translated packet's IP header, into/from the address fields in the translated packet's IP header,
skipping to change at page 9, line 42 skipping to change at page 9, line 46
Discovery [RFC4861] messages for them) and routed through the Discovery [RFC4861] messages for them) and routed through the
translation function before being forwarded out its downstream translation function before being forwarded out its downstream
interface as IPv4 packets. The downstream network segment thus interface as IPv4 packets. The downstream network segment thus
becomes dual-stacked. becomes dual-stacked.
4. Deployment Considerations 4. Deployment Considerations
4.1. IPv6 Path MTU 4.1. IPv6 Path MTU
The IPv6 Path MTU between the ER and the BR will typically be larger The IPv6 Path MTU between the ER and the BR will typically be larger
than the default value defined in Section 4 of [RFC6145] (1280), as than the default value defined in Section 4 of [RFC6145] (1280
it will typically contained within a single administrative domain. bytes), as it will typically contained within a single administrative
Therefore, it is RECOMMENDED that the IPv6 Path MTU configured in the domain. Therefore, it is RECOMMENDED that the IPv6 Path MTU
ER is raised accordingly. It is RECOMMENDED that the ER and the BR configured in the ER is raised accordingly. It is RECOMMENDED that
use identical configured IPv6 Path MTU values. the ER and the BR use identical configured IPv6 Path MTU values.
4.2. IPv4 MTU 4.2. IPv4 MTU
In order to avoid IPv6 fragmentation, an ER SHOULD ensure that the In order to avoid IPv6 fragmentation, an ER SHOULD ensure that the
IPv4 MTU used by applications or nodes is equal to the configured IPv4 MTU used by applications or nodes is equal to the configured
IPv6 Path MTU - 20, so that an maximum-sized IPv4 packet can fit in IPv6 Path MTU - 20, so that an maximum-sized IPv4 packet can fit in
an unfragmented IPv6 packet. This ensures that the application may an unfragmented IPv6 packet. This ensures that the application may
do its part in avoiding IP-level fragmentation from occurring, e.g., do its part in avoiding IP-level fragmentation from occurring, e.g.,
by segmenting/fragmenting outbound packets at the application layer, by segmenting/fragmenting outbound packets at the application layer,
and advertising the maximum size its peer may use for inbound packets and advertising the maximum size its peer may use for inbound packets
skipping to change at page 11, line 4 skipping to change at page 11, line 4
Although SIIT-DC is primarily intended to facilitate communication Although SIIT-DC is primarily intended to facilitate communication
between IPv4-only nodes on the Internet and services located in an between IPv4-only nodes on the Internet and services located in an
IPv6-only IDC network, an IPv4-only node or application located IPv6-only IDC network, an IPv4-only node or application located
behind an ER might need to communicate with other nodes or services behind an ER might need to communicate with other nodes or services
in the IDC. The IPv4-only node or application will need to so in the IDC. The IPv4-only node or application will need to so
through the ER, as it will typically be incapable to contact IPv6 through the ER, as it will typically be incapable to contact IPv6
destinations directly. The following subsections discusses various destinations directly. The following subsections discusses various
methods on how to facilitate such communication. methods on how to facilitate such communication.
5.1. Hairpinning by the SIIT-DC Border Relay 5.1. Hairpinning by the SIIT-DC Border Relay
If the BR supports hairpinning as described in Section 4.2 of I-D If the BR supports hairpinning as described in Section 4.2 of
.ietf-v6ops-siit-eam [I-D.ietf-v6ops-siit-eam], the easiest solution [I-D.ietf-v6ops-siit-eam], the easiest solution is to make the target
is to make the target service available through SIIT-DC in the normal service available through SIIT-DC in the normal way, that is, by
way, that is, by provisioning an EAM to the BR that assigns an IPv4 provisioning an EAM to the BR that assigns an IPv4 Service Address
Service Address with the target service's IPv6 Service Address. with the target service's IPv6 Service Address.
This allows the IPv4-only node or application to transmit packets This allows the IPv4-only node or application to transmit packets
destined for the target service's IPv4 Service Address, which the ER destined for the target service's IPv4 Service Address, which the ER
will then translate to a corresponding IPv4-converted IPv6 address by will then translate to a corresponding IPv4-converted IPv6 address by
inserting the Translation Prefix [RFC6052]. When this IPv6 packet inserting the Translation Prefix [RFC6052]. When this IPv6 packet
reaches the BR, it will be hairpinned and transmitted back to the reaches the BR, it will be hairpinned and transmitted back to the
target service's IPv6 Service Address (where it could possibly pass target service's IPv6 Service Address (where it could possibly pass
through another ER before reaching the target service). Return through another ER before reaching the target service). Return
traffic from the target service will be hairpinned in the same traffic from the target service will be hairpinned in the same
fashion. fashion.
skipping to change at page 13, line 35 skipping to change at page 13, line 35
6. Acknowledgements 6. Acknowledgements
The author would like to especially thank the authors of 464XLAT The author would like to especially thank the authors of 464XLAT
[RFC6877]: Masataka Mawatari, Masanobu Kawashima, and Cameron Byrne. [RFC6877]: Masataka Mawatari, Masanobu Kawashima, and Cameron Byrne.
The architecture described by this document is merely an adaptation The architecture described by this document is merely an adaptation
of their work to a data centre environment, and could not have of their work to a data centre environment, and could not have
happened without them. happened without them.
The author would like also to thank the following individuals for The author would like also to thank the following individuals for
their contributions, suggestions, corrections, and criticisms: Fred their contributions, suggestions, corrections, and criticisms: Fred
Baker, Tobias Brox, Ray Hunter, Shucheng LIU (Will), Andrew Baker, Tobias Brox, Olafur Gudmundsson, Christer Holmberg, Ray
Yourtchenko. Hunter, Shucheng LIU (Will), Andrew Yourtchenko.
7. IANA Considerations 7. IANA Considerations
This draft makes no request of the IANA. The RFC Editor may remove This draft makes no request of the IANA.
this section prior to publication.
8. Security Considerations 8. Security Considerations
This section discusses security considerations specific to the use of This section discusses security considerations specific to the use of
an ER. See the Security Considerations section in an ER. See the Security Considerations section in
[I-D.ietf-v6ops-siit-dc] for additional security considerations [I-D.ietf-v6ops-siit-dc] for security considerations applicable to
applicable to the SIIT-DC architecture in general. the SIIT-DC architecture in general.
8.1. Address Spoofing
If the ER receives an IPv4 packet from the application/node from a If the ER receives an IPv4 packet from the application/node from a
source address it does not have an EAM for, both the source and source address it does not have an EAM for, both the source and
destination addresses will be rewritten according to [RFC6052]. destination addresses will be rewritten according to [RFC6052].
After undergoing the reverse translation in the BR, the resulting After undergoing the reverse translation in the BR, the resulting
IPv4 packet routed to the IPv4 network will have a spoofed IPv4 IPv4 packet routed to the IPv4 network will have a spoofed IPv4
source address. The ER SHOULD therefore ensure that ingress source address. The ER SHOULD therefore ensure that ingress
filtering [RFC2827] is used on the ER's IPv4 interface, so that such filtering [RFC2827] is used on the ER's IPv4 interface, so that such
packets are immediately discarded. packets are immediately discarded.
If the ER receives an IPv6 packet with both the source and If the ER receives an IPv6 packet with both the source and
skipping to change at page 14, line 31 skipping to change at page 14, line 27
IPv6 Service Addresses, or 2) after translation from IPv6 to IPv4, IPv6 Service Addresses, or 2) after translation from IPv6 to IPv4,
equal to any of its local IPv4 Service Addresses. equal to any of its local IPv4 Service Addresses.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-v6ops-siit-dc] [I-D.ietf-v6ops-siit-dc]
Anderson, T., "SIIT-DC: Stateless IP/ICMP Translation for Anderson, T., "SIIT-DC: Stateless IP/ICMP Translation for
IPv6 Data Centre Environments", draft-ietf-v6ops-siit- IPv6 Data Centre Environments", draft-ietf-v6ops-siit-
dc-00 (work in progress), December 2014. dc-02 (work in progress), August 2015.
[I-D.ietf-v6ops-siit-eam] [I-D.ietf-v6ops-siit-eam]
Anderson, T. and A. Leiva, "Explicit Address Mappings for Anderson, T. and A. Leiva, "Explicit Address Mappings for
Stateless IP/ICMP Translation", draft-ietf-v6ops-siit- Stateless IP/ICMP Translation", draft-ietf-v6ops-siit-
eam-00 (work in progress), May 2015. eam-01 (work in progress), June 2015.
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
9.2. Informative References 9.2. Informative References
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet Converting Network Protocol Addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD 37, Address for Transmission on Ethernet Hardware", STD 37,
RFC 826, November 1982. RFC 826, DOI 10.17487/RFC0826, November 1982,
<http://www.rfc-editor.org/info/rfc826>.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
E. Lear, "Address Allocation for Private Internets", BCP and E. Lear, "Address Allocation for Private Internets",
5, RFC 1918, February 1996. BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<http://www.rfc-editor.org/info/rfc1918>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997. 2131, DOI 10.17487/RFC2131, March 1997,
<http://www.rfc-editor.org/info/rfc2131>.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
<http://www.rfc-editor.org/info/rfc2132>.
[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, May 2000. Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <http://www.rfc-editor.org/info/rfc2827>.
[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,
September 2007. DOI 10.17487/RFC4861, September 2007,
<http://www.rfc-editor.org/info/rfc4861>.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010. DOI 10.17487/RFC6052, October 2010,
<http://www.rfc-editor.org/info/rfc6052>.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011. Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011,
<http://www.rfc-editor.org/info/rfc6145>.
[RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts [RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts
Using "Bump-in-the-Host" (BIH)", RFC 6535, February 2012. Using "Bump-in-the-Host" (BIH)", RFC 6535, DOI 10.17487/
RFC6535, February 2012,
<http://www.rfc-editor.org/info/rfc6535>.
[RFC6724] Thaler, D., 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, September 2012. (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<http://www.rfc-editor.org/info/rfc6724>.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation", RFC Combination of Stateful and Stateless Translation", RFC
6877, April 2013. 6877, DOI 10.17487/RFC6877, April 2013,
<http://www.rfc-editor.org/info/rfc6877>.
[RFC7335] Byrne, C., "IPv4 Service Continuity Prefix", RFC 7335, [RFC7335] Byrne, C., "IPv4 Service Continuity Prefix", RFC 7335, DOI
August 2014. 10.17487/RFC7335, August 2014,
<http://www.rfc-editor.org/info/rfc7335>.
Appendix A. Examples: Network-Based IPv4 Connectivity Appendix A. Examples: Network-Based IPv4 Connectivity
A.1. Subnet with IPv4 Service Addresses A.1. Subnet with IPv4 Service Addresses
One relatively straight-forward way to provide IPv4 connectivity One relatively straight-forward way to provide IPv4 connectivity
between the ER and the IPv4 node(s) it serves is to ensure the IPv4 between the ER and the IPv4 node(s) it serves is to ensure the IPv4
Service Address(es) can be enclosed within a larger IPv4 prefix. The Service Address(es) can be enclosed within a larger IPv4 prefix. The
ER may then claim one address in this prefix for itself, and use it ER may then claim one address in this prefix for itself, and use it
to provide an IPv4 default router address. The ER may then proceed to provide an IPv4 default router address. The ER may then proceed
to assign the IPv4 Service Address(es) to its downstream node(s) to assign the IPv4 Service Address(es) to its downstream node(s)
using DHCPv4 [RFC2131]. For example, if the IPv4 Service Addresses using DHCPv4 [RFC2131]. For example, if the IPv4 Service Addresses
are 192.0.2.26 and 192.0.2.27, the ER would configure the address are 192.0.2.26 and 192.0.2.27, the ER would configure the address
192.0.2.25/29 on its IPv4-facing interface and would add the two IPv4 192.0.2.25/29 on its IPv4-facing interface and would add the two IPv4
Service Addresses to its DHCPv4 pool. Service Addresses to its DHCPv4 pool.
 End of changes. 34 change blocks. 
59 lines changed or deleted 74 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/