draft-ietf-v6ops-rfc7084-bis-01.txt   draft-ietf-v6ops-rfc7084-bis-02.txt 
IPv6 Operations (v6ops) J. Palet Martinez IPv6 Operations (v6ops) J. Palet Martinez
Internet-Draft Consulintel, S.L. Internet-Draft Consulintel, S.L.
Obsoletes: 7084 (if approved) April 10, 2017 Obsoletes: 7084 (if approved) May 27, 2017
Intended status: Informational Intended status: Informational
Expires: October 12, 2017 Expires: November 28, 2017
Basic Requirements for IPv6 Customer Edge Routers Basic Requirements for IPv6 Customer Edge Routers
draft-ietf-v6ops-rfc7084-bis-01 draft-ietf-v6ops-rfc7084-bis-02
Abstract Abstract
This document specifies requirements for an IPv6 Customer Edge (CE) This document specifies requirements for an IPv6 Customer Edge (CE)
router. Specifically, the current version of this document focuses router. Specifically, the current version of this document focuses
on the basic provisioning of an IPv6 CE router and the provisioning on the basic provisioning of an IPv6 CE router and the provisioning
of IPv6 hosts attached to it. The document also covers several of IPv6 hosts attached to it. The document also covers several
transition technologies, as required in a world where IPv4 addresses transition technologies, as required in a world where IPv4 addresses
are no longer available, so hosts in the customer LANs with IPv4-only are no longer available, so hosts in the customer LANs with IPv4-only
or IPv6-only applications or devices, requiring to communicate with or IPv6-only applications or devices, requiring to communicate with
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 October 12, 2017. This Internet-Draft will expire on November 28, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 18 skipping to change at page 2, line 18
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 4 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 4
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Current IPv4 End-User Network Architecture . . . . . . . 6 4.1. Current IPv4 End-User Network Architecture . . . . . . . 6
4.2. IPv6 End-User Network Architecture . . . . . . . . . . . 6 4.2. IPv6 End-User Network Architecture . . . . . . . . . . . 7
4.2.1. Local Communication . . . . . . . . . . . . . . . . . 8 4.2.1. Local Communication . . . . . . . . . . . . . . . . . 8
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. General Requirements . . . . . . . . . . . . . . . . . . 8 5.1. General Requirements . . . . . . . . . . . . . . . . . . 8
5.2. WAN-Side Configuration . . . . . . . . . . . . . . . . . 9 5.2. WAN-Side Configuration . . . . . . . . . . . . . . . . . 9
5.3. LAN-Side Configuration . . . . . . . . . . . . . . . . . 13 5.3. LAN-Side Configuration . . . . . . . . . . . . . . . . . 13
5.4. Transition Technologies Support . . . . . . . . . . . . . 15 5.4. Transition Technologies Support . . . . . . . . . . . . . 15
5.4.1. 464XLAT . . . . . . . . . . . . . . . . . . . . . . . 15 5.4.1. IPv4 Service Continuity in Customer LANs . . . . . . 15
5.4.2. 6in4 . . . . . . . . . . . . . . . . . . . . . . . . 15 5.4.1.1. 464XLAT . . . . . . . . . . . . . . . . . . . . . 15
5.4.3. 6rd . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.4.1.2. Dual-Stack Lite (DS-Lite) . . . . . . . . . . . . 16
5.4.4. Dual-Stack Lite (DS-Lite) . . . . . . . . . . . . . . 18 5.4.1.3. Lightweight 4over6 (lw4o6) . . . . . . . . . . . 17
5.4.5. Lightweight 4over6 (lw4o6) . . . . . . . . . . . . . 19 5.4.1.4. MAP-E . . . . . . . . . . . . . . . . . . . . . . 17
5.4.6. MAP-E . . . . . . . . . . . . . . . . . . . . . . . . 19 5.4.1.5. MAP-T . . . . . . . . . . . . . . . . . . . . . . 18
5.4.7. MAP-T . . . . . . . . . . . . . . . . . . . . . . . . 20 5.4.2. Support of IPv6 in IPv4-only WAN access . . . . . . . 18
5.5. IPv4 Multicast Support . . . . . . . . . . . . . . . . . 20 5.4.2.1. 6in4 . . . . . . . . . . . . . . . . . . . . . . 18
5.4.2.2. 6rd . . . . . . . . . . . . . . . . . . . . . . . 19
5.5. IPv4 Multicast Support . . . . . . . . . . . . . . . . . 21
5.6. Security Considerations . . . . . . . . . . . . . . . . . 21 5.6. Security Considerations . . . . . . . . . . . . . . . . . 21
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22
8. ANNEX A: Code Considerations . . . . . . . . . . . . . . . . 22 8. ANNEX A: Code Considerations . . . . . . . . . . . . . . . . 22
9. ANNEX B: Changes from RFC7084 . . . . . . . . . . . . . . . . 23 9. ANNEX B: Changes from RFC7084 . . . . . . . . . . . . . . . . 23
10. ANNEX C: Changes from RFC7084-bis-00 . . . . . . . . . . . . 23 10. ANNEX C: Changes from RFC7084-bis-00 . . . . . . . . . . . . 23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 11. ANNEX D: Changes from RFC7084-bis-01 . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . 24 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . 29 12.1. Normative References . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29 12.2. Informative References . . . . . . . . . . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
This document defines basic IPv6 features for a residential or small- This document defines basic IPv6 features for a residential or small-
office router, referred to as an "IPv6 CE router", in order to office router, referred to as an "IPv6 CE router", in order to
establish an industry baseline for features to be implemented on such establish an industry baseline for features to be implemented on such
a router. a router.
These routers typically also support IPv4, at least in the LAN side. These routers typically also support IPv4, at least in the LAN side.
This document specifies how an IPv6 CE router automatically This document specifies how an IPv6 CE router automatically
provisions its WAN interface, acquires address space for provisioning provisions its WAN interface, acquires address space for provisioning
of its LAN interfaces, and fetches other configuration information of its LAN interfaces, and fetches other configuration information
from the service provider network. Automatic provisioning of more from the service provider network. Automatic provisioning of more
complex topology than a single router with multiple LAN interfaces is complex topology than a single router with multiple LAN interfaces is
out of scope for this document. In some cases, manual provisioning out of scope for this document. In some cases, manual provisioning
may be acceptable, when intended for a small number of customers. may be acceptable, when intended for a small number of customers.
See [RFC4779] for a discussion of options available for deploying This document doesn't cover the specific details of each possible
IPv6 in service provider access networks. access technology. For example, if the CE is supporting built-in or
external 3GPP/LTE interfaces, [RFC7849] is a relevant reference. See
[RFC4779] for a discussion of options available for deploying IPv6 in
wireline service provider access networks.
This document also covers the IP transition technologies required in This document also covers the IP transition technologies required in
a world where IPv4 addresses are no longer available, so the service a world where IPv4 addresses are no longer available, so the service
providers need to provision IPv6-only WAN access, while at the same providers need to provision IPv6-only WAN access, while at the same
time ensuring that IPv4-only or IPv6-only devices or applications in time ensuring that IPv4-only or IPv6-only devices or applications in
the customer LANs can still reach IPv4-only devices or applications the customer LANs can still reach IPv4-only devices or applications
in Internet, which still don't have IPv6 support. in Internet, which still don't have IPv6 support.
1.1. Requirements Language 1.1. Requirements Language
skipping to change at page 4, line 23 skipping to change at page 4, line 30
IPv6 CE router may have one or more IPv6 CE router may have one or more
network-layer LAN interfaces. network-layer LAN interfaces.
Service Provider an entity that provides access to the Service Provider an entity that provides access to the
Internet. In this document, a service Internet. In this document, a service
provider specifically offers Internet provider specifically offers Internet
access using IPv6, and it may also offer access using IPv6, and it may also offer
IPv4 Internet access. The service provider IPv4 Internet access. The service provider
can provide such access over a variety of can provide such access over a variety of
different transport methods such as FTTH, different transport methods such as FTTH,
DSL, cable, wireless, LTE, and others. DSL, cable, wireless, 3GPP/LTE, and others.
WAN Interface an IPv6 CE router's attachment to a link WAN Interface an IPv6 CE router's attachment to a link
used to provide connectivity to the service used to provide connectivity to the service
provider network; example link technologies provider network; example link technologies
include Ethernet (simple or bridged), PPP include Ethernet (simple or bridged), PPP
links, Frame Relay, or ATM networks, as links, Frame Relay, or ATM networks, as
well as Internet-layer (or higher-layer) well as Internet-layer (or higher-layer)
"tunnels", such as tunnels over IPv4 or "tunnels", such as tunnels over IPv4 or
IPv6 itself. IPv6 itself.
skipping to change at page 5, line 44 skipping to change at page 6, line 4
tracking connections, etc. So, it is out of the scope of this tracking connections, etc. So, it is out of the scope of this
document to classify them. document to classify them.
For example, an SME may have just 10 employees (micro-SME), which For example, an SME may have just 10 employees (micro-SME), which
commonly will be considered same as a SOHO, but a small SME can have commonly will be considered same as a SOHO, but a small SME can have
up to 50 employees, or 250 for a medium one. Depending on the IPv6 up to 50 employees, or 250 for a medium one. Depending on the IPv6
CE router capabilities or even how it is being configured (for CE router capabilities or even how it is being configured (for
instance, using SLAAC or DHCPv6), it may support even a higher number instance, using SLAAC or DHCPv6), it may support even a higher number
of employees if the traffic in the LANs is low, or switched by of employees if the traffic in the LANs is low, or switched by
another device(s), or the WAN bandwidth requirements are low, etc. another device(s), or the WAN bandwidth requirements are low, etc.
The actual bandwidth capabilities of access with technologies such as The actual bandwidth capabilities of access with technologies such as
FTTH, cable and even LTE, allows the support of such usages, and FTTH, cable and even 3GPP/LTE, allows the support of such usages, and
indeed, is a very common situation that access networks and the CE indeed, is a very common situation that access networks and the CE
provided by the service provider are the same for SMEs and provided by the service provider are the same for SMEs and
residential users. residential users.
There is also no difference in terms of who actually provides the There is also no difference in terms of who actually provides the
IPv6 CE router. In most of the cases is the service provider, and in IPv6 CE router. In most of the cases is the service provider, and in
fact is responsible, typically, of provisioning/managing at least the fact is responsible, typically, of provisioning/managing at least the
WAN side. However, commonly the user has access to configure the LAN WAN side. However, commonly the user has access to configure the LAN
interfaces, firewall, DMZ, and many other aspects. In fact, in many interfaces, firewall, DMZ, and many other aspects. In fact, in many
cases, the user must supply, or at least can replace the IPv6 CE cases, the user must supply, or at least can replace the IPv6 CE
skipping to change at page 9, line 28 skipping to change at page 9, line 31
originates [RFC4861]. originates [RFC4861].
G-5: By default, if the IPv6 CE router is an advertising router and G-5: By default, if the IPv6 CE router is an advertising router and
loses its IPv6 default router(s) and/or detects loss of loses its IPv6 default router(s) and/or detects loss of
connectivity on the WAN interface, it MUST explicitly connectivity on the WAN interface, it MUST explicitly
invalidate itself as an IPv6 default router on each of its invalidate itself as an IPv6 default router on each of its
advertising interfaces by immediately transmitting one or more advertising interfaces by immediately transmitting one or more
Router Advertisement messages with the "Router Lifetime" field Router Advertisement messages with the "Router Lifetime" field
set to zero [RFC4861]. set to zero [RFC4861].
G-6: The IPv6 CE router MUST comply with [RFC7608].
5.2. WAN-Side Configuration 5.2. WAN-Side Configuration
The IPv6 CE router will need to support connectivity to one or more The IPv6 CE router will need to support connectivity to one or more
access network architectures. This document describes an IPv6 CE access network architectures. This document describes an IPv6 CE
router that is not specific to any particular architecture or service router that is not specific to any particular architecture or service
provider and that supports all commonly used architectures. provider and that supports all commonly used architectures.
IPv6 Neighbor Discovery and DHCPv6 protocols operate over any type of IPv6 Neighbor Discovery and DHCPv6 protocols operate over any type of
IPv6-supported link layer, and there is no need for a link-layer- IPv6-supported link layer, and there is no need for a link-layer-
specific configuration protocol for IPv6 network-layer configuration specific configuration protocol for IPv6 network-layer configuration
skipping to change at page 15, line 24 skipping to change at page 15, line 26
L-15: The IPv6 CE router MUST send an ICMPv6 Destination Unreachable L-15: The IPv6 CE router MUST send an ICMPv6 Destination Unreachable
message, code 5 (Source address failed ingress/egress policy) message, code 5 (Source address failed ingress/egress policy)
for packets forwarded to it that use an address from a prefix for packets forwarded to it that use an address from a prefix
that has been invalidated. that has been invalidated.
L-16: The IPv6 CE router SHOULD provide HNCP (Home Networking L-16: The IPv6 CE router SHOULD provide HNCP (Home Networking
Control Protocol) services, as specified in [RFC7788]. Control Protocol) services, as specified in [RFC7788].
5.4. Transition Technologies Support 5.4. Transition Technologies Support
5.4.1. 464XLAT Even if the main target of this document is the support of IPv6-only
WAN access, for some time, there will be a need to support IPv4-only
devices and applications in the customers LANs, in one side of the
picture. In the other side, some Service Providers willing to deploy
IPv6, may not be able to do so in the first stage, neither as
IPv6-only or dual-stack in the WAN. Consequently, transition
technologies to resolve both issues should be taken in consideration.
5.4.1. IPv4 Service Continuity in Customer LANs
5.4.1.1. 464XLAT
464XLAT [RFC6877] is a technique to provide IPv4 access service to 464XLAT [RFC6877] is a technique to provide IPv4 access service to
IPv6-only edge networks without encapsulation. IPv6-only edge networks without encapsulation.
The CE router SHOULD support CLAT functionality. If 464XLAT is The CE router SHOULD support CLAT functionality. If 464XLAT is
supported, it MUST be implemented according to [RFC6877]. The supported, it MUST be implemented according to [RFC6877]. The
following CE Requirements also apply: following CE Requirements also apply:
464XLAT requirements: 464XLAT requirements:
skipping to change at page 15, line 48 skipping to change at page 16, line 13
using DHCPv6-PD [RFC3633]. using DHCPv6-PD [RFC3633].
464XLAT-2: The CE router MUST implement [RFC7050] in order to 464XLAT-2: The CE router MUST implement [RFC7050] in order to
discover the PLAT-side translation IPv4 and IPv6 discover the PLAT-side translation IPv4 and IPv6
prefix(es)/suffix(es). In environments with PCP support, prefix(es)/suffix(es). In environments with PCP support,
the CE SHOULD follow [RFC7225] to learn the PLAT-side the CE SHOULD follow [RFC7225] to learn the PLAT-side
translation IPv4 and IPv6 prefix(es)/suffix(es) used by translation IPv4 and IPv6 prefix(es)/suffix(es) used by
an upstream PCP-controlled NAT64 device. Alternatively an upstream PCP-controlled NAT64 device. Alternatively
SHOULD support draft-li-intarea-nat64-prefix-dhcp-option. SHOULD support draft-li-intarea-nat64-prefix-dhcp-option.
5.4.2. 6in4 5.4.1.2. Dual-Stack Lite (DS-Lite)
6in4 [RFC4213] specifies a tunneling mechanism to allow end-users to
manually configure IPv6 support via a service provider's IPv4 network
infrastructure.
The CE router MAY support 6in4 functionality. If 6rd is implemented,
6in4 MUST be supported as well. If 6in4 is supported, it MUST be
implemented according to [RFC4213]. The following CE Requirements
also apply:
6in4 requirements:
6IN4-1: The IPv6 CE router SHOULD support 6in4 automated
configuration by means of the 6rd DHCPv4 Option 212. If the
CE router has obtained an IPv4 network address through some
other means such as PPP, it SHOULD use the DHCPINFORM
request message [RFC2131] to request the 6rd DHCPv4 Option.
The IPv6 CE router MAY use other mechanisms to configure
6in4 parameters. Such mechanisms are outside the scope of
this document.
6IN4-2: If the IPv6 CE router is capable of automated configuration
of IPv4 through IPCP (i.e., over a PPP connection), it MUST
support user-entered configuration of 6in4.
6IN4-3: If the CE router supports configuration mechanisms other
than the 6rd DHCPv4 Option 212 (user-entered, TR-069
[TR-069], etc.), the CE router MUST support 6in4 in "hub and
spoke" mode. 6in4 in "hub and spoke" requires all IPv6
traffic to go to the 6rd Border Relay. In effect, this
requirement removes the "direct connect to 6rd" route
defined in Section 7.1.1 of [RFC5969].
6IN4-4: A CE router MUST allow 6in4 and native IPv6 WAN interfaces
to be active alone as well as simultaneously in order to
support coexistence of the two technologies during an
incremental transition period such as a transition from 6in4
to native IPv6.
6IN4-5: Each packet sent on a 6in4 or native WAN interface MUST be
directed such that its source IP address is derived from the
delegated prefix associated with the particular interface
from which the packet is being sent (Section 4.3 of
[RFC3704]).
6IN4-6: The CE router MUST allow different as well as identical
delegated prefixes to be configured via each (6in4 or
native) WAN interface.
6IN4-7: In the event that forwarding rules produce a tie between
6in4 and native IPv6, by default, the IPv6 CE router MUST
prefer native IPv6.
5.4.3. 6rd
6rd [RFC5969] specifies an automatic tunneling mechanism tailored to
advance deployment of IPv6 to end users via a service provider's IPv4
network infrastructure. Key aspects include automatic IPv6 prefix
delegation to sites, stateless operation, simple provisioning, and
service that is equivalent to native IPv6 at the sites that are
served by the mechanism. It is expected that such traffic is
forwarded over the CE router's native IPv4 WAN interface and not
encapsulated in another tunnel.
The CE router MAY support 6rd functionality. If 6rd is supported, it
MUST be implemented according to [RFC5969]. The following CE
Requirements also apply:
6rd requirements:
6RD-1: The IPv6 CE router MUST support 6rd configuration via the 6rd
DHCPv4 Option 212. If the CE router has obtained an IPv4
network address through some other means such as PPP, it
SHOULD use the DHCPINFORM request message [RFC2131] to
request the 6rd DHCPv4 Option. The IPv6 CE router MAY use
other mechanisms to configure 6rd parameters. Such
mechanisms are outside the scope of this document.
6RD-2: If the IPv6 CE router is capable of automated configuration
of IPv4 through IPCP (i.e., over a PPP connection), it MUST
support user-entered configuration of 6rd.
6RD-3: If the CE router supports configuration mechanisms other than
the 6rd DHCPv4 Option 212 (user-entered, TR-069 [TR-069],
etc.), the CE router MUST support 6rd in "hub and spoke"
mode. 6rd in "hub and spoke" requires all IPv6 traffic to go
to the 6rd Border Relay. In effect, this requirement removes
the "direct connect to 6rd" route defined in Section 7.1.1 of
[RFC5969].
6RD-4: A CE router MUST allow 6rd and native IPv6 WAN interfaces to
be active alone as well as simultaneously in order to support
coexistence of the two technologies during an incremental
transition period such as a transition from 6rd to native
IPv6.
6RD-5: Each packet sent on a 6rd or native WAN interface MUST be
directed such that its source IP address is derived from the
delegated prefix associated with the particular interface
from which the packet is being sent (Section 4.3 of
[RFC3704]).
6RD-6: The CE router MUST allow different as well as identical
delegated prefixes to be configured via each (6rd or native)
WAN interface.
6RD-7: In the event that forwarding rules produce a tie between 6rd
and native IPv6, by default, the IPv6 CE router MUST prefer
native IPv6.
5.4.4. Dual-Stack Lite (DS-Lite)
Dual-Stack Lite [RFC6333] enables both continued support for IPv4 Dual-Stack Lite [RFC6333] enables both continued support for IPv4
services and incentives for the deployment of IPv6. It also services and incentives for the deployment of IPv6. It also
de-couples IPv6 deployment in the service provider network from the de-couples IPv6 deployment in the service provider network from the
rest of the Internet, making incremental deployment easier. Dual- rest of the Internet, making incremental deployment easier. Dual-
Stack Lite enables a broadband service provider to share IPv4 Stack Lite enables a broadband service provider to share IPv4
addresses among customers by combining two well-known technologies: addresses among customers by combining two well-known technologies:
IP in IP (IPv4-in-IPv6) and Network Address Translation (NAT). It is IP in IP (IPv4-in-IPv6) and Network Address Translation (NAT). It is
expected that DS-Lite traffic is forwarded over the CE router's expected that DS-Lite traffic is forwarded over the CE router's
native IPv6 WAN interface, and not encapsulated in another tunnel. native IPv6 WAN interface, and not encapsulated in another tunnel.
skipping to change at page 19, line 5 skipping to change at page 17, line 5
described in [RFC8026]. described in [RFC8026].
DSLITE-3: The IPv6 CE router MUST NOT perform IPv4 Network Address DSLITE-3: The IPv6 CE router MUST NOT perform IPv4 Network Address
Translation (NAT) on IPv4 traffic encapsulated using DS- Translation (NAT) on IPv4 traffic encapsulated using DS-
Lite. Lite.
DSLITE-4: If the IPv6 CE router is configured with an IPv4 address DSLITE-4: If the IPv6 CE router is configured with an IPv4 address
on its WAN interface, then the IPv6 CE router SHOULD on its WAN interface, then the IPv6 CE router SHOULD
disable the DS-Lite Basic Bridging BroadBand (B4) element. disable the DS-Lite Basic Bridging BroadBand (B4) element.
5.4.5. Lightweight 4over6 (lw4o6) 5.4.1.3. Lightweight 4over6 (lw4o6)
Lw4o6 [RFC7596] specifies an extension to DS-Lite, which moves the Lw4o6 [RFC7596] specifies an extension to DS-Lite, which moves the
NAPT function from the DS-Lite tunnel concentrator to the tunnel NAPT function from the DS-Lite tunnel concentrator to the tunnel
client located in the IPv6 CE router, removing the requirement for a client located in the IPv6 CE router, removing the requirement for a
CGN function in the tunnel concentrator and reducing the amount of CGN function in the tunnel concentrator and reducing the amount of
centralized state. centralized state.
The IPv6 CE router SHOULD implement lw4o6 functionality. If DS-Lite The IPv6 CE router SHOULD implement lw4o6 functionality. If DS-Lite
is implemented, lw4o6 MUST be supported as well. If lw4o6 is is implemented, lw4o6 MUST be supported as well. If lw4o6 is
supported, it MUST be implemented according to [RFC7596]. This supported, it MUST be implemented according to [RFC7596]. This
skipping to change at page 19, line 35 skipping to change at page 17, line 35
LW4O6-2: The CE router MUST support the DHCPv6 S46 priority option LW4O6-2: The CE router MUST support the DHCPv6 S46 priority option
described in [RFC8026]. described in [RFC8026].
LW4O6-3: The CE router MUST support the DHCPv4-over-DHCPv6 (DHCP LW4O6-3: The CE router MUST support the DHCPv4-over-DHCPv6 (DHCP
4o6) transport described in [RFC7341]. 4o6) transport described in [RFC7341].
LW4O6-4: The CE router MAY support Dynamic Allocation of Shared IPv4 LW4O6-4: The CE router MAY support Dynamic Allocation of Shared IPv4
Addresses as described in [RFC7618]. Addresses as described in [RFC7618].
LW4O6-5: The IPv6 CE router MUST perform port-restricted IPv4 LW4O6-5: If the IPv6 CE router is configured with an IPv4 address on
Network Address Translation (NAT) on IPv4 traffic
encapsulated using lw4o6.
LW4O6-6: If the IPv6 CE router is configured with an IPv4 address on
its WAN interface, then the IPv6 CE router SHOULD disable its WAN interface, then the IPv6 CE router SHOULD disable
the Lightweight Basic Bridging BroadBand (B4) element. the Lightweight Basic Bridging BroadBand (B4) element.
5.4.6. MAP-E 5.4.1.4. MAP-E
MAP-E [RFC7597] is a mechanism for transporting IPv4 packets across MAP-E [RFC7597] is a mechanism for transporting IPv4 packets across
an IPv6 network using IP encapsulation, including a generic mechanism an IPv6 network using IP encapsulation, including a generic mechanism
for mapping between IPv6 addresses and IPv4 addresses as well as for mapping between IPv6 addresses and IPv4 addresses as well as
transport-layer ports. transport-layer ports.
The CE router SHOULD support MAP-E functionality. If MAP-E is The CE router SHOULD support MAP-E functionality. If MAP-E is
supported, it MUST be implemented according to [RFC7597]. The supported, it MUST be implemented according to [RFC7597]. The
following CE Requirements also apply: following CE Requirements also apply:
MAP-E requirements: MAP-E requirements:
MAPE-1: The CE router MUST support configuration of MAP-E via the MAPE-1: The CE router MUST support configuration of MAP-E via the
MAP-E DHCPv6 options [RFC7598]. The IPv6 CE router MAY use MAP-E DHCPv6 options [RFC7598]. The IPv6 CE router MAY use
other mechanisms to configure MAP-E parameters. Such other mechanisms to configure MAP-E parameters. Such
mechanisms are outside the scope of this document. mechanisms are outside the scope of this document.
MAPE-2: The CE router MUST support the DHCPv6 S46 priority option MAPE-2: The CE router MUST support the DHCPv6 S46 priority option
described in [RFC8026]. described in [RFC8026].
MAPE-3: The IPv6 CE router MUST perform port-restricted IPv4 Network 5.4.1.5. MAP-T
Address Translation (NAT) on IPv4 traffic encapsulated using
MAP-E.
5.4.7. MAP-T
MAP-T [RFC7599] is a mechanism similar to MAP-E, differing from it in MAP-T [RFC7599] is a mechanism similar to MAP-E, differing from it in
that MAP-T uses IPv4-IPv6 translation, rather than encapsulation, as that MAP-T uses IPv4-IPv6 translation, rather than encapsulation, as
the form of IPv6 domain transport. the form of IPv6 domain transport.
The CE router SHOULD support MAP-T functionality. If MAP-T is The CE router SHOULD support MAP-T functionality. If MAP-T is
supported, it MUST be implemented according to [RFC7599]. The supported, it MUST be implemented according to [RFC7599]. The
following CE Requirements also apply: following CE Requirements also apply:
MAP-T requirements: MAP-T requirements:
MAPT-1: The CE router MUST support configuration of MAP-T via the MAPT-1: The CE router MUST support configuration of MAP-T via the
MAP-E DHCPv6 options [RFC7598]. The IPv6 CE router MAY use MAP-E DHCPv6 options [RFC7598]. The IPv6 CE router MAY use
other mechanisms to configure MAP-E parameters. Such other mechanisms to configure MAP-E parameters. Such
mechanisms are outside the scope of this document. mechanisms are outside the scope of this document.
MAPT-2: The CE router MUST support the DHCPv6 S46 priority option MAPT-2: The CE router MUST support the DHCPv6 S46 priority option
described in [RFC8026]. described in [RFC8026].
MAPT-3: The IPv6 CE router MUST perform port-restricted IPv4 Network 5.4.2. Support of IPv6 in IPv4-only WAN access
Address Translation (NAT) on IPv4 traffic translated using
MAP-T. 5.4.2.1. 6in4
6in4 [RFC4213] specifies a tunneling mechanism to allow end-users to
manually configure IPv6 support via a service provider's IPv4 network
infrastructure.
The CE router MAY support 6in4 functionality. 6in4 used for a
manually configured tunnel requires a subset of the 6rd parameters
(delegated prefix and remote IPv4 end-point). The on-wire and
forwarding plane is identical for both mechanisms, however 6in4
doesn't support mesh traffic and requires manually provisioning.
Thus, if the device supports either 6rd or 6in4, it's commonly a
minor UI addition to support both. If 6in4 is supported, it MUST be
implemented according to [RFC4213]. The following CE Requirements
also apply:
6in4 requirements:
6IN4-1: The IPv6 CE router SHOULD support 6in4 automated
configuration by means of the 6rd DHCPv4 Option 212. If the
CE router has obtained an IPv4 network address through some
other means such as PPP, it SHOULD use the DHCPINFORM
request message [RFC2131] to request the 6rd DHCPv4 Option.
The IPv6 CE router MAY use other mechanisms to configure
6in4 parameters. Such mechanisms are outside the scope of
this document.
6IN4-2: If the IPv6 CE router is capable of automated configuration
of IPv4 through IPCP (i.e., over a PPP connection), it MUST
support user-entered configuration of 6in4.
6IN4-3: If the CE router supports configuration mechanisms other
than the 6rd DHCPv4 Option 212 (user-entered, TR-069
[TR-069], etc.), the CE router MUST support 6in4 in "hub and
spoke" mode. 6in4 in "hub and spoke" requires all IPv6
traffic to go to the 6rd Border Relay, which in this case is
the tunnel-end-point. In effect, this requirement removes
the "direct connect to 6rd" route defined in Section 7.1.1
of [RFC5969].
6IN4-4: A CE router MUST allow 6in4 and native IPv6 WAN interfaces
to be active alone as well as simultaneously in order to
support coexistence of the two technologies during an
incremental transition period such as a transition from 6in4
to native IPv6.
6IN4-5: Each packet sent on a 6in4 or native WAN interface MUST be
directed such that its source IP address is derived from the
delegated prefix associated with the particular interface
from which the packet is being sent (Section 4.3 of
[RFC3704]).
6IN4-6: The CE router MUST allow different as well as identical
delegated prefixes to be configured via each (6in4 or
native) WAN interface.
6IN4-7: In the event that forwarding rules produce a tie between
6in4 and native IPv6, by default, the IPv6 CE router MUST
prefer native IPv6.
5.4.2.2. 6rd
6rd [RFC5969] specifies an automatic tunneling mechanism tailored to
advance deployment of IPv6 to end users via a service provider's IPv4
network infrastructure. Key aspects include automatic IPv6 prefix
delegation to sites, stateless operation, simple provisioning, and
service that is equivalent to native IPv6 at the sites that are
served by the mechanism. It is expected that such traffic is
forwarded over the CE router's native IPv4 WAN interface and not
encapsulated in another tunnel.
The CE router MAY support 6rd functionality. If 6rd is supported, it
MUST be implemented according to [RFC5969]. The following CE
Requirements also apply:
6rd requirements:
6RD-1: The IPv6 CE router MUST support 6rd configuration via the 6rd
DHCPv4 Option 212. If the CE router has obtained an IPv4
network address through some other means such as PPP, it
SHOULD use the DHCPINFORM request message [RFC2131] to
request the 6rd DHCPv4 Option. The IPv6 CE router MAY use
other mechanisms to configure 6rd parameters. Such
mechanisms are outside the scope of this document.
6RD-2: If the IPv6 CE router is capable of automated configuration
of IPv4 through IPCP (i.e., over a PPP connection), it MUST
support user-entered configuration of 6rd.
6RD-3: If the CE router supports configuration mechanisms other than
the 6rd DHCPv4 Option 212 (user-entered, TR-069 [TR-069],
etc.), the CE router MUST support 6rd in "hub and spoke"
mode. 6rd in "hub and spoke" requires all IPv6 traffic to go
to the 6rd Border Relay. In effect, this requirement removes
the "direct connect to 6rd" route defined in Section 7.1.1 of
[RFC5969].
6RD-4: A CE router MUST allow 6rd and native IPv6 WAN interfaces to
be active alone as well as simultaneously in order to support
coexistence of the two technologies during an incremental
transition period such as a transition from 6rd to native
IPv6.
6RD-5: Each packet sent on a 6rd or native WAN interface MUST be
directed such that its source IP address is derived from the
delegated prefix associated with the particular interface
from which the packet is being sent (Section 4.3 of
[RFC3704]).
6RD-6: The CE router MUST allow different as well as identical
delegated prefixes to be configured via each (6rd or native)
WAN interface.
6RD-7: In the event that forwarding rules produce a tie between 6rd
and native IPv6, by default, the IPv6 CE router MUST prefer
native IPv6.
5.5. IPv4 Multicast Support 5.5. IPv4 Multicast Support
Actual deployments support IPv4 multicast for services such as IPTV. Actual deployments support IPv4 multicast for services such as IPTV.
In the transition phase it is expected that multicast services will In the transition phase it is expected that multicast services will
still be provided using IPv4 to the customer LANs. still be provided using IPv4 to the customer LANs.
In order to support the delivery of IPv4 multicast services to IPv4 In order to support the delivery of IPv4 multicast services to IPv4
clients over an IPv6 multicast network, the CE router SHOULD support clients over an IPv6 multicast network, the CE router SHOULD support
[RFC8114] and [RFC8115]. [RFC8114] and [RFC8115].
skipping to change at page 21, line 36 skipping to change at page 21, line 47
was downgraded from a MUST from RFC 6204 due to the difficulty was downgraded from a MUST from RFC 6204 due to the difficulty
of implementation in the CE router and the feature's redundancy of implementation in the CE router and the feature's redundancy
with upstream router ingress filtering. with upstream router ingress filtering.
S-3: If the IPv6 CE router firewall is configured to filter incoming S-3: If the IPv6 CE router firewall is configured to filter incoming
tunneled data, the firewall SHOULD provide the capability to tunneled data, the firewall SHOULD provide the capability to
filter decapsulated packets from a tunnel. filter decapsulated packets from a tunnel.
6. Acknowledgements 6. Acknowledgements
Thanks to Mohamed Boucadair, Masanobu Kawashima and Mikael Thanks to James Woodyatt, Mohamed Boucadair, Masanobu Kawashima,
Abrahamsson for their review and comments. Mikael Abrahamsson, Barbara Stark and Ole Troan for their review and
comments.
This document is an update of RFC7084, whose original authors were: This document is an update of RFC7084, whose original authors were:
Hemant Singh, Wes Beebee, Chris Donley and Barbara Stark. The rest Hemant Singh, Wes Beebee, Chris Donley and Barbara Stark. The rest
of the text on this section and the Contributors section, are the of the text on this section and the Contributors section, are the
original acknowledgements and Contributors sections of the earlier original acknowledgements and Contributors sections of the earlier
version of this document. version of this document.
Thanks to the following people (in alphabetical order) for their Thanks to the following people (in alphabetical order) for their
guidance and feedback: guidance and feedback:
Mikael Abrahamsson, Tore Anderson, Merete Asak, Rajiv Asati, Scott Mikael Abrahamsson, Tore Anderson, Merete Asak, Rajiv Asati, Scott
Beuker, Mohamed Boucadair, Rex Bullinger, Brian Carpenter, Tassos Beuker, Mohamed Boucadair, Rex Bullinger, Brian Carpenter, Tassos
skipping to change at page 23, line 29 skipping to change at page 23, line 40
6. As the main scope of this document is the IPv6-only CE (IPv6-only 6. As the main scope of this document is the IPv6-only CE (IPv6-only
in the WAN link), the support of 6rd ([RFC5969]) has been changed in the WAN link), the support of 6rd ([RFC5969]) has been changed
to MAY. 6in4 ([RFC4213]) support has been included as well in to MAY. 6in4 ([RFC4213]) support has been included as well in
case 6rd is supported, as it doesn't require additional code. case 6rd is supported, as it doesn't require additional code.
7. New section "IPv4 Multicast Support". 7. New section "IPv4 Multicast Support".
8. Added support for DNS proxy [RFC5625] as general LAN requirement. 8. Added support for DNS proxy [RFC5625] as general LAN requirement.
9. Split of transition in two sub-sections for the sake of clarity.
10. ANNEX C: Changes from RFC7084-bis-00 10. ANNEX C: Changes from RFC7084-bis-00
Section to be removed for WGLC. Significant updates are: Section to be removed for WGLC. Significant updates are:
1. LW4O6-5 changed to port-restricted to conform with [RFC7596]. 1. LW4O6-5 changed to port-restricted to conform with [RFC7596].
2. MAPE-3 changed to port-restricted to conform with [RFC7597]. 2. MAPE-3 changed to port-restricted to conform with [RFC7597].
3. MAPT-3 changed to port-restricted to conform with [RFC7599]. 3. MAPT-3 changed to port-restricted to conform with [RFC7599].
4. [RFC7341] removed from 464XLAT, DS-LITE, MAP-E and MAP-T 4. [RFC7341] removed from 464XLAT, DS-LITE, MAP-E and MAP-T
requirements. requirements.
5. [RFC5625] removed from 464XLAT, and included as general LAN 5. [RFC5625] removed from 464XLAT, and included as general LAN
requirement. requirement.
6. [RFC7618] included as MAY for lw4o6. 6. [RFC7618] included as MAY for lw4o6.
11. References 7. 6in4 text clarifications.
11.1. Normative References
8. Included non-normative reference to [RFC7849] to clarify that the
details of the connectivity to 3GPP/LTE networks is out of the
scope.
9. Split of transition in two sub-sections for the sake of clarity.
11. ANNEX D: Changes from RFC7084-bis-01
Section to be removed for WGLC. Significant updates are:
1. G-5 added in order to comply with [RFC7608].
2. LW4O6-5 removed.
3. MAPE-3 removed.
4. MAPT-3 removed.
5. Included non-normative reference to [RFC7849] to clarify that the
details of the connectivity to 3GPP/LTE networks is out of the
scope.
6. Split of transition in two sub-sections for the sake of clarity.
12. References
12.1. Normative References
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<http://www.rfc-editor.org/info/rfc1122>. <http://www.rfc-editor.org/info/rfc1122>.
[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>.
skipping to change at page 28, line 27 skipping to change at page 29, line 16
W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for
Configuration of Softwire Address and Port-Mapped Configuration of Softwire Address and Port-Mapped
Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015, Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015,
<http://www.rfc-editor.org/info/rfc7598>. <http://www.rfc-editor.org/info/rfc7598>.
[RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S.,
and T. Murakami, "Mapping of Address and Port using and T. Murakami, "Mapping of Address and Port using
Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July
2015, <http://www.rfc-editor.org/info/rfc7599>. 2015, <http://www.rfc-editor.org/info/rfc7599>.
[RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix
Length Recommendation for Forwarding", BCP 198, RFC 7608,
DOI 10.17487/RFC7608, July 2015,
<http://www.rfc-editor.org/info/rfc7608>.
[RFC7618] Cui, Y., Sun, Q., Farrer, I., Lee, Y., Sun, Q., and M. [RFC7618] Cui, Y., Sun, Q., Farrer, I., Lee, Y., Sun, Q., and M.
Boucadair, "Dynamic Allocation of Shared IPv4 Addresses", Boucadair, "Dynamic Allocation of Shared IPv4 Addresses",
RFC 7618, DOI 10.17487/RFC7618, August 2015, RFC 7618, DOI 10.17487/RFC7618, August 2015,
<http://www.rfc-editor.org/info/rfc7618>. <http://www.rfc-editor.org/info/rfc7618>.
[RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking
Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April
2016, <http://www.rfc-editor.org/info/rfc7788>. 2016, <http://www.rfc-editor.org/info/rfc7788>.
[RFC8026] Boucadair, M. and I. Farrer, "Unified IPv4-in-IPv6 [RFC8026] Boucadair, M. and I. Farrer, "Unified IPv4-in-IPv6
skipping to change at page 29, line 5 skipping to change at page 29, line 46
Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients
over an IPv6 Multicast Network", RFC 8114, over an IPv6 Multicast Network", RFC 8114,
DOI 10.17487/RFC8114, March 2017, DOI 10.17487/RFC8114, March 2017,
<http://www.rfc-editor.org/info/rfc8114>. <http://www.rfc-editor.org/info/rfc8114>.
[RFC8115] Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6 [RFC8115] Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6
Option for IPv4-Embedded Multicast and Unicast IPv6 Option for IPv4-Embedded Multicast and Unicast IPv6
Prefixes", RFC 8115, DOI 10.17487/RFC8115, March 2017, Prefixes", RFC 8115, DOI 10.17487/RFC8115, March 2017,
<http://www.rfc-editor.org/info/rfc8115>. <http://www.rfc-editor.org/info/rfc8115>.
11.2. Informative References 12.2. Informative References
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144,
April 2011, <http://www.rfc-editor.org/info/rfc6144>.
[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>.
[RFC7550] Troan, O., Volz, B., and M. Siodelski, "Issues and [RFC7550] Troan, O., Volz, B., and M. Siodelski, "Issues and
Recommendations with Multiple Stateful DHCPv6 Options", Recommendations with Multiple Stateful DHCPv6 Options",
RFC 7550, DOI 10.17487/RFC7550, May 2015, RFC 7550, DOI 10.17487/RFC7550, May 2015,
<http://www.rfc-editor.org/info/rfc7550>. <http://www.rfc-editor.org/info/rfc7550>.
[RFC7849] Binet, D., Boucadair, M., Vizdal, A., Chen, G., Heatley,
N., Chandler, R., Michaud, D., Lopez, D., and W. Haeffner,
"An IPv6 Profile for 3GPP Mobile Devices", RFC 7849,
DOI 10.17487/RFC7849, May 2016,
<http://www.rfc-editor.org/info/rfc7849>.
[TR-069] Broadband Forum, "CPE WAN Management Protocol", TR-069 [TR-069] Broadband Forum, "CPE WAN Management Protocol", TR-069
Amendment 4, July 2011, Amendment 4, July 2011,
<http://www.broadband-forum.org/technical/trlist.php>. <http://www.broadband-forum.org/technical/trlist.php>.
[UPnP-IGD] [UPnP-IGD]
UPnP Forum, , "InternetGatewayDevice:2 Device Template UPnP Forum, , "InternetGatewayDevice:2 Device Template
Version 1.01", December 2010, Version 1.01", December 2010,
<http://upnp.org/specs/gw/igd2/>. <http://upnp.org/specs/gw/igd2/>.
Author's Address Author's Address
 End of changes. 26 change blocks. 
158 lines changed or deleted 211 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/