draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt   draft-ietf-v6ops-ipv6-cpe-router-bis-01.txt 
Internet Engineering Task Force H. Singh Internet Engineering Task Force H. Singh
Internet-Draft W. Beebee Internet-Draft W. Beebee
Intended status: Informational Cisco Systems, Inc. Intended status: Informational Cisco Systems, Inc.
Expires: September 6, 2011 C. Donley Expires: January 12, 2012 C. Donley
CableLabs CableLabs
B. Stark B. Stark
AT&T ATT
O. Troan, Ed. O. Troan, Ed.
Cisco Systems, Inc. Cisco Systems, Inc.
March 5, 2011 July 11, 2011
Advanced Requirements for IPv6 Customer Edge Routers Advanced Requirements for IPv6 Customer Edge Routers
draft-ietf-v6ops-ipv6-cpe-router-bis-00 draft-ietf-v6ops-ipv6-cpe-router-bis-01
Abstract Abstract
This document continues the work undertaken by the IPv6 CE Router This document continues the work undertaken by the IPv6 CE Router
Phase I work in the IETF v6ops Working Group. Advanced requirements Phase I work in the IETF v6ops Working Group. Advanced requirements
or Phase II work is covered in this document. or Phase II work is covered in this document.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 September 6, 2011. This Internet-Draft will expire on January 12, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 19 skipping to change at page 2, line 19
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Conceptual Configuration Variables . . . . . . . . . . . . . . 4 3. Conceptual Configuration Variables . . . . . . . . . . . . . . 4
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Advanced Features and Feature Requirements . . . . . . . . . . 6 5. Advanced Features and Feature Requirements . . . . . . . . . . 6
5.1. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Multicast Behavior . . . . . . . . . . . . . . . . . . . . 6 5.2. Multicast Behavior . . . . . . . . . . . . . . . . . . . . 6
5.3. ND Proxy . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.3. Routed network behavior . . . . . . . . . . . . . . . . . 7
5.4. Routed network behavior . . . . . . . . . . . . . . . . . 8 5.4. Transition Technologies Support . . . . . . . . . . . . . 7
5.5. Transition Technologies Support . . . . . . . . . . . . . 8 5.4.1. Dual-Stack(DS)-Lite . . . . . . . . . . . . . . . . . 7
5.5.1. Dual-Stack(DS)-Lite . . . . . . . . . . . . . . . . . 8 5.4.2. 6rd . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.5.2. 6rd . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.4.3. Transition Technologies Coexistence . . . . . . . . . 9
5.5.3. Transition Technologies Coexistence . . . . . . . . . 10 5.5. Quality Of Service . . . . . . . . . . . . . . . . . . . . 10
5.6. Quality Of Service . . . . . . . . . . . . . . . . . . . . 10 5.6. Unicast Data Forwarding . . . . . . . . . . . . . . . . . 10
5.7. Unicast Data Forwarding . . . . . . . . . . . . . . . . . 10 5.7. Additional DHCPv6 WAN Requirement . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
This document defines Advanced IPv6 features for a residential or This document defines Advanced IPv6 features for a residential or
small office router referred to as an IPv6 CE router. Typically small office router referred to as an IPv6 CE router. Typically
these routers also support IPv4. The IPv6 End-user Network these routers also support IPv4. The IPv6 End-user Network
Architecture for such a router is described in Architecture for such a router is described in [RFC6204]. This
[I-D.ietf-v6ops-ipv6-cpe-router]. This version of the document version of the document includes the requirements for Advanced
includes the requirements for Advanced features. features.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Terminology 2. Terminology
End-user Network one or more links attached to the IPv6 CE End-user Network one or more links attached to the IPv6 CE
skipping to change at page 4, line 21 skipping to change at page 4, line 21
"tunnels", such as tunnels over IPv4 or "tunnels", such as tunnels over IPv4 or
IPv6 itself. IPv6 itself.
3. Conceptual Configuration Variables 3. Conceptual Configuration Variables
The CE Router maintains such a list of conceptual optional The CE Router maintains such a list of conceptual optional
configuration variables. configuration variables.
1. Enable an IGP on the LAN. 1. Enable an IGP on the LAN.
2. Configure 6rd configuration.
3. Configure IPv6 for 6rd to have IPv6 traffic go to the 6rd Border
Relay vs. directly to peers.
4. Architecture 4. Architecture
This document extends the architecture described in This document extends the architecture described in [RFC6204] to
[I-D.ietf-v6ops-ipv6-cpe-router] to cover a strictly larger set of cover a strictly larger set of operational scenarios. In particular,
operational scenarios. In particular, QoS, multicast, DNS, routed QoS, multicast, DNS, routed network in the home, transition
network in the home, transition technologies, and conceptual technologies, and conceptual configuration variables. This document
configuration variables. This document also extends the model also extends the model described in [RFC6204] to a two router
described in [I-D.ietf-v6ops-ipv6-cpe-router] to a two router
topology where the two routers are connected back-to-back (the LAN of topology where the two routers are connected back-to-back (the LAN of
one router is connected to the WAN of the other router). This one router is connected to the WAN of the other router). This
topology is depicted below: topology is depicted below:
+-------+-------+ \ +-------+-------+ \
| Service | \ | Service | \
| Provider | | Service | Provider | | Service
| Router | | Provider | Router | | Provider
+-------+-------+ | network +-------+-------+ | network
| / | /
skipping to change at page 6, line 14 skipping to change at page 6, line 14
5. Advanced Features and Feature Requirements 5. Advanced Features and Feature Requirements
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 supports all commonly used architectures. Provider, and supports all commonly used architectures.
5.1. DNS 5.1. DNS
D-1: For local DNS queries for configuration, the CE Router MAY D-1: The CE Router MAY include a DNS server authoritative for .local
include a DNS server to handle local queries. Non-local to handle local queries. If the service provider specifies one
queries can be forwarded unchanged to a DNS server specified in or more DNS resolvers in DHCP configuration options, the CE
the DNS server DHCPv6 option. The CE Router MAY also include router SHOULD forward all non-local DNS queries unchanged to
DNS64 functionality which is specified in those servers. The CE Router MAY also include DNS64
[I-D.bagnulo-behave-dns64]. functionality which is specified in [RFC6147].
D-2: The local DNS server MAY also handle renumbering from the
Service Provider provided prefix for local names used
exclusively inside the home (the local AAAA and PTR records are
updated). This capability provides connectivity using local
DNS names in the home after a Service Provider renumbering. A
CE Router MAY add local DNS entries based on dynamic requests
from the LAN segment(s). The protocol to carry such requests
from hosts to the CE Router is yet to be described.
5.2. Multicast Behavior 5.2. Multicast Behavior
This section is only applicable to a CE Router with at least one LAN This section is only applicable to a CE Router with at least one LAN
interface. A host in the home is expected to receive multicast interface. A host in the home is expected to receive multicast
video. Note the CE Router resides at edge of the home and the video. Note the CE Router resides at edge of the home and the
Service Provider, and the CE Router has at least one WAN connection Service Provider, and the CE Router has at least one WAN connection
for multiple LAN connections. In such a multiple LAN to a WAN for multiple LAN connections. In such a multiple LAN to a WAN
toplogy at the CE Router edge, it is not necessary to run a multicast toplogy at the CE Router edge, it is not necessary to run a multicast
routing protocol and thus MLD Proxy as specified in [RFC4605] can be routing protocol and thus MLD Proxy as specified in [RFC4605] can be
skipping to change at page 7, line 20 skipping to change at page 7, line 12
LMMLD-1: The CPE Router MUST follow the model described for MLD LMMLD-1: The CPE Router MUST follow the model described for MLD
Proxy in [RFC4605] to implement multicast. Proxy in [RFC4605] to implement multicast.
LMMLD-2: Consistent with [RFC4605], the LAN interfaces on the CPE LMMLD-2: Consistent with [RFC4605], the LAN interfaces on the CPE
router MUST NOT implement an MLDv2 Multicast Listener. router MUST NOT implement an MLDv2 Multicast Listener.
LAN requirements: LAN requirements:
LM-1: If the CE Router has bridging configured between the LAN LM-1: If the CE Router has bridging configured between the LAN
interfaces, then the LAN interfaces MUST support snooping of interfaces, then the LAN interfaces MUST support snooping of
MLD [RFC3810] messages. MLD [RFC3810] messages as per [RFC4541] .
5.3. ND Proxy
LAN requirements:
LNDP-1: If the CE Router has only one /64 prefix to be used across
multiple LAN interfaces and the CE Router supports any two
LAN interfaces that cannot bridge data between them because
the two interfaces have disparate MAC layers, then the CE
Router MUST support Proxying Neighbor Advertisements as
specified in Section 7.2.8 of [RFC4861]. If any two LAN
interfaces support bridging between the interfaces, then
Proxying Neighbor Advertisements is not necessary between
the two interfaces. Legacy 3GPP networks have the following
requirements:
1. No DHCPv6 prefix is delegated to the CE Router.
2. Only one /64 is available on the WAN link.
3. The link types between the WAN interface and LAN
interface(s) are disparate and, therefore, can't be
bridged.
4. No NAT66 is to be used.
5. Each LAN interface needs global connectivity.
6. Uses SLAAC to configure LAN interface addresses.
For these legacy 3GPP networks, the CPE Router MUST support
ND Proxy between the WAN and LAN interface(s). If a CE
Router will never be deployed in an environment with these
characteristics, then ND Proxy is not necessary.
5.4. Routed network behavior 5.3. Routed network behavior
CPE Router Behavior in a routed network: CPE Router Behavior in a routed network:
R-1: One example of the CPE Router use in the home is shown below. R-1: One example of the CPE Router use in the home is shown below.
The home has a broadband modem combined with a CPE Router, all The home has a broadband modem combined with a CPE Router, all
in one device. The LAN interface of the device is connected to in one device. The LAN interface of the device is connected to
another standalone CPE Router that supports a wireless access another standalone CPE Router that supports a wireless access
point. To support such a network, this document recommends point. To support such a network, this document recommends
using prefix delegation of the prefix obtained either via IA_PD using prefix delegation of the prefix obtained either via IA_PD
from WAN interface or a ULA from the LAN interface. The from WAN interface or a ULA from the LAN interface. The
skipping to change at page 8, line 36 skipping to change at page 7, line 43
and IGP in the home network. and IGP in the home network.
/-------+------------\ /------------+-----\ /-------+------------\ /------------+-----\
SP <--+ Modem | CPE Router +--+ CPE Router | WAP + --> PC SP <--+ Modem | CPE Router +--+ CPE Router | WAP + --> PC
\-------+------------/ \------------+-----/ \-------+------------/ \------------+-----/
WAP = Wireless Access Point WAP = Wireless Access Point
Figure 2. Figure 2.
5.5. Transition Technologies Support 5.4. Transition Technologies Support
5.5.1. Dual-Stack(DS)-Lite 5.4.1. Dual-Stack(DS)-Lite
Even as users migrate from IPv4 to IPv6 addressing, a significant Even as users migrate from IPv4 to IPv6 addressing, a significant
percentage of Internet resources and content will remain accessible percentage of Internet resources and content will remain accessible
only through IPv4. Also, many end-user devices will only support only through IPv4. Also, many end-user devices will only support
IPv4. As a consequence, Service Providers require mechanisms to IPv4. As a consequence, Service Providers require mechanisms to
allow customers to continue to access content and resources using allow customers to continue to access content and resources using
IPv4 even after the last IPv4 allocations have been fully depleted. IPv4 even after the last IPv4 allocations have been fully depleted.
One technology that can be used for IPv4 address extension is DS- One technology that can be used for IPv4 address extension is DS-
Lite. Lite.
skipping to change at page 9, line 44 skipping to change at page 9, line 5
address on its WAN interface, where public IPv4 address is address on its WAN interface, where public IPv4 address is
defined as any address which is not in the private IP address defined as any address which is not in the private IP address
space specified in [RFC1918] and also not in the reserved IP space specified in [RFC1918] and also not in the reserved IP
address space specified in address space specified in
[I-D.ietf-softwire-dual-stack-lite], then the IPv6 CE Router [I-D.ietf-softwire-dual-stack-lite], then the IPv6 CE Router
MUST disable the DS-Lite B4 element. MUST disable the DS-Lite B4 element.
DLW-5: If DS-Lite is operational on the IPv6 CE Router, multicast DLW-5: If DS-Lite is operational on the IPv6 CE Router, multicast
data MUST NOT be sent on any DS-Lite tunnel. data MUST NOT be sent on any DS-Lite tunnel.
5.5.2. 6rd 5.4.2. 6rd
The IPv6 CE Router can be used to offer IPv6 service to a LAN, even The IPv6 CE Router can be used to offer IPv6 service to a LAN, even
when the WAN access network only supports IPv4. One technology that when the WAN access network only supports IPv4. One technology that
supports IPv6 service over an IPv4 network is IPv6 Rapid Deployment supports IPv6 service over an IPv4 network is IPv6 Rapid Deployment
(6rd). 6rd encapsulates IPv6 traffic from the end user LAN inside (6rd). 6rd encapsulates IPv6 traffic from the end user LAN inside
IPv4 at the IPv6 CE Router and sends it to a Service Provider Border IPv4 at the IPv6 CE Router and sends it to a Service Provider Border
Relay (BR). The IPv6 CE Router calculates a 6rd delegated IPv6 Relay (BR). The IPv6 CE Router calculates a 6rd delegated IPv6
prefix during 6rd configuration, and sub-delegates the 6rd delegated prefix during 6rd configuration, and sub-delegates the 6rd delegated
prefix to devices in the LAN. prefix to devices in the LAN.
The IPv6 CE Router SHOULD implement 6rd functionality as specified in The IPv6 CE Router SHOULD implement 6rd functionality as specified in
[RFC5969]. [RFC5969].
6rd requirements: 6rd requirements:
6RD-1: If the IPv6 CE Router implements 6rd functionality, the CE 6RD-1: If the IPv6 CE Router implements 6rd functionality, the CE
Router WAN interface MUST support at least one 6rd Virtual Router WAN interface MUST support at least one 6rd Virtual
Interface and 6rd CE functionality as specified in [RFC5969]. Interface and 6rd CE functionality as specified in [RFC5969].
6RD-2: If the IPv6 CE Router implements 6rd CE functionality, it 6RD-2: If the IPv6 CE Router implements 6rd CE functionality, it
MUST support using the 6rd DHCPv4 Option (212) for 6rd MUST support user-entered configuration and using the 6rd
configuration. The IPv6 CE Router MAY use other mechanisms DHCPv4 Option (212) for 6rd configuration. The IPv6 CE
to configure 6rd parameters. Such mechanisms are outside the Router MAY use other mechanisms to configure 6rd parameters.
scope of this document. Such mechanisms are outside the scope of this document.
6RD-3: If 6rd is operational on the IPv6 CE Router, multicast data 6RD-3: If the CE router implements 6rd functionality, it MUST allow
the user to specify whether all IPv6 traffic goes to the 6rd
Border Relay, or whether other destinations within the same
6rd domain are routed directly to those destinations. The CE
router MAY use other mechanisms to configure this. Such
mechanisms are outside the scope of this document.
6RD-4: If 6rd is operational on the IPv6 CE Router, multicast data
MUST NOT be sent on any 6rd tunnel. MUST NOT be sent on any 6rd tunnel.
5.5.3. Transition Technologies Coexistence 5.4.3. Transition Technologies Coexistence
Run the following four in parallel to provision CPE router Run the following four in parallel to provision CPE router
connectivity to the Service Provider: connectivity to the Service Provider:
1. Initiate IPv4 address acquisition. 1. Initiate IPv4 address acquisition.
2. Initiate IPv6 address acquisition as specified by 2. Initiate IPv6 address acquisition as specified by [RFC6204].
[I-D.ietf-v6ops-ipv6-cpe-router].
3. If 6rd is provisioned, initiate 6rd. 3. If 6rd is provisioned, initiate 6rd.
4. If DS-Lite is provisioned, initiate DS-Lite. 4. If DS-Lite is provisioned, initiate DS-Lite.
The default route for IPv6 through the native physical interface The default route for IPv6 through the native physical interface
should have preference over the 6rd tunnel interface. The default should have preference over the 6rd tunnel interface. The default
route for IPv4 through the native physical interface should have route for IPv4 through the native physical interface should have
preference over the DS-Lite tunnel interface. preference over the DS-Lite tunnel interface.
5.6. Quality Of Service 5.5. Quality Of Service
Q-1: The CPE router MAY support differentiated services [RFC2474]. Q-1: The CPE router MAY support differentiated services [RFC2474].
5.7. Unicast Data Forwarding 5.6. Unicast Data Forwarding
The null route introduced by the WPD-6 requirement in The null route introduced by the WPD-6 requirement in [RFC6204] has
[I-D.ietf-v6ops-ipv6-cpe-router] has lower precedence than other lower precedence than other routes except for the default route.
routes except for the default route.
5.7. Additional DHCPv6 WAN Requirement
When the WAN interface sends a DHCPV6 SOLICIT message, the CE router
SHOULD request all mandatory information (IA_NA and IA_PD options) in
the SOLICIT regardless of whether any partial information was
received in response to previous SOLICITs.
6. Security Considerations 6. Security Considerations
None. None.
7. Acknowledgements 7. Acknowledgements
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:
skipping to change at page 12, line 4 skipping to change at page 11, line 21
The following people have participated as co-authors or provided The following people have participated as co-authors or provided
substantial contributions to this document: Ralph Droms, Kirk substantial contributions to this document: Ralph Droms, Kirk
Erichsen, Fred Baker, Jason Weil, Lee Howard, Jean-Francois Tremblay, Erichsen, Fred Baker, Jason Weil, Lee Howard, Jean-Francois Tremblay,
Yiu Lee, John Jason Brzozowski and Heather Kirksey. Yiu Lee, John Jason Brzozowski and Heather Kirksey.
9. IANA Considerations 9. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
10. References 10. References
10.1. Normative References
[I-D.bagnulo-behave-dns64] 10.1. Normative References
Bagnulo, M., Sullivan, A., Matthews, P., Beijnum, I., and
M. Endo, "DNS64: DNS extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers",
draft-bagnulo-behave-dns64-02 (work in progress),
March 2009.
[I-D.ietf-softwire-ds-lite-tunnel-option] [I-D.ietf-softwire-ds-lite-tunnel-option]
Hankins, D. and T. Mrugalski, "Dynamic Host Configuration Hankins, D. and T. Mrugalski, "Dynamic Host Configuration
Protocol for IPv6 (DHCPv6) Option for Dual- Stack Lite", Protocol for IPv6 (DHCPv6) Option for Dual- Stack Lite",
draft-ietf-softwire-ds-lite-tunnel-option-09 (work in draft-ietf-softwire-ds-lite-tunnel-option-10 (work in
progress), March 2011. progress), March 2011.
[I-D.ietf-softwire-dual-stack-lite] [I-D.ietf-softwire-dual-stack-lite]
Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4 Stack Lite Broadband Deployments Following IPv4
Exhaustion", draft-ietf-softwire-dual-stack-lite-07 (work Exhaustion", draft-ietf-softwire-dual-stack-lite-11 (work
in progress), March 2011. in progress), May 2011.
[I-D.ietf-v6ops-ipv6-cpe-router]
Singh, H., Beebee, W., Donley, C., Stark, B., and O.
Troan, "Basic Requirements for IPv6 Customer Edge
Routers", draft-ietf-v6ops-ipv6-cpe-router-09 (work in
progress), December 2010.
[I-D.vyncke-advanced-ipv6-security] [I-D.vyncke-advanced-ipv6-security]
Vyncke, E. and M. Townsley, "Advanced Security for IPv6 Vyncke, E. and M. Townsley, "Advanced Security for IPv6
CPE", draft-vyncke-advanced-ipv6-security-01 (work in CPE", draft-vyncke-advanced-ipv6-security-01 (work in
progress), March 2010. progress), March 2010.
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
skipping to change at page 14, line 45 skipping to change at page 14, line 5
Version 2 (L2TPv2)", RFC 5571, June 2009. Version 2 (L2TPv2)", RFC 5571, June 2009.
[RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet
Model: The Relationship between Links and Subnet Model: The Relationship between Links and Subnet
Prefixes", RFC 5942, July 2010. Prefixes", RFC 5942, July 2010.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd) -- Protocol Specification", Infrastructures (6rd) -- Protocol Specification",
RFC 5969, August 2010. RFC 5969, August 2010.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
April 2011.
[RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O.
Troan, "Basic Requirements for IPv6 Customer Edge
Routers", RFC 6204, April 2011.
10.2. Informative References 10.2. Informative References
[I-D.ietf-behave-v6v4-framework] [I-D.ietf-behave-v6v4-framework]
Baker, F., Li, X., Bao, C., and K. Yin, "Framework for Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation", IPv4/IPv6 Translation",
draft-ietf-behave-v6v4-framework-10 (work in progress), draft-ietf-behave-v6v4-framework-10 (work in progress),
August 2010. August 2010.
[UPnP-IGD] [UPnP-IGD]
UPnP Forum, "Universal Plug and Play (UPnP) Internet UPnP Forum, "Universal Plug and Play (UPnP) Internet
skipping to change at page 15, line 31 skipping to change at page 15, line 4
Wes Beebee Wes Beebee
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Ave. 1414 Massachusetts Ave.
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Phone: +1 978 936 2030 Phone: +1 978 936 2030
Email: wbeebee@cisco.com Email: wbeebee@cisco.com
URI: http://www.cisco.com/ URI: http://www.cisco.com/
Chris Donley Chris Donley
CableLabs CableLabs
858 Coal Creek Circle 858 Coal Creek Circle
Louisville, CO 80027 Louisville, CO 80027
USA USA
Email: c.donley@cablelabs.com Email: c.donley@cablelabs.com
Barbara Stark Barbara Stark
AT&T ATT
725 W Peachtree St 725 W Peachtree St
Atlanta, GA 30308 Atlanta, GA 30308
USA USA
Email: barbara.stark@att.com Email: barbara.stark@att.com
Ole Troan (editor) Ole Troan (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Veversmauet 8 Veversmauet 8
N-5017 BERGEN, N-5017 BERGEN,
Norway Norway
Email: ot@cisco.com Email: ot@cisco.com
 End of changes. 32 change blocks. 
112 lines changed or deleted 82 lines changed or added

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