< draft-liu-softwire-lw4over6-dynamic-provisioning-01.txt   draft-liu-softwire-lw4over6-dynamic-provisioning-02.txt >
Network Working Group C. Liu Network Working Group C. Liu
Internet-Draft Q. Sun Internet-Draft Q. Sun
Intended status: Informational J. Wu Intended status: Informational J. Wu
Expires: September 22, 2016 Tsinghua University Expires: December 31, 2016 Tsinghua University
I. Farrer I. Farrer
Deutsche Telekom AG Deutsche Telekom AG
March 21, 2016 June 29, 2016
Dynamic IPv4 Provisioning for Lightweight 4over6 Dynamic IPv4 Provisioning for Lightweight 4over6
draft-liu-softwire-lw4over6-dynamic-provisioning-01 draft-liu-softwire-lw4over6-dynamic-provisioning-02
Abstract Abstract
Lightweight 4over6 [RFC7596] is an IPv4 over IPv6 hub-and-spoke Lightweight 4over6 [RFC7596] is an IPv4 over IPv6 hub-and-spoke
mechanism that provides overlay IPv4 services in an IPv6-only access mechanism that provides overlay IPv4 services in an IPv6-only access
network. It uses a deterministic, DHCPv6 based method for the network. It uses a deterministic, DHCPv6 based method for the
provisioning of IPv4 addresses and port sets to customer CE devices. provisioning of IPv4 addresses and port sets to customer CE devices.
This document describes how existing specifications can be used for This document describes how existing specifications can be used for
the dynamic IPv4 provisioning of Lightweight 4over6, based on DHCPv4 the dynamic IPv4 provisioning of Lightweight 4over6, based on DHCPv4
over DHCPv6 [RFC7341]. over DHCPv6 [RFC7341].
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 September 22, 2016. This Internet-Draft will expire on December 31, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 4 3. Dynamic Provisioning Model . . . . . . . . . . . . . . . . . 4
4. Lightweight4over6 Dynamic Provisioning Process . . . . . . . 5 3.1. Flow 1: lwB4's IPv6 Addressing and DHCPv6 Configuration . 4
4.1. Client IPv6 Addressing . . . . . . . . . . . . . . . . . 5 3.2. Flow 2: DHCP 4o6 Function . . . . . . . . . . . . . . . . 5
4.2. DHCPv6 Configuration . . . . . . . . . . . . . . . . . . 5 3.3. Flow 3: lwAFTR Binding Table Maintainence . . . . . . . . 5
4.3. DHCPv4 over DHCPv6 Function . . . . . . . . . . . . . . . 5 3.3.1. Flow 3a: Binding Table Maintenance for Co-located
4.4. lwAFTR Binding Table Maintenance . . . . . . . . . . . . 5 lwAFTR/DHCP 4o6 Functions . . . . . . . . . . . 5
4.4.1. Co-located lwAFTR/DHCP4o6 Binding Table Maintenance . 6 3.3.2. Flow 3b: Binding Table Maintenance for Distributed
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 lwAFTR/DHCP 4o6 Functions . . . . . . . . . . . 6
5.1. Data Retention Requirements . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 4.1. Data Retention Requirements . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
Lightweight 4over6 [RFC7596] provides IPv4 access over an IPv6 Lightweight 4over6 [RFC7596] (lw4o6) provides IPv4 access over an
network in hub-and-spoke softwire architecture. In Lightweight IPv6 network with a hub-and-spoke softwire architecture. In
4over6, each Lightweight B4 (lwB4) is assigned a full, or shared Lightweight 4over6, each Lightweight B4 (lwB4) is assigned a full, or
(port-restricted) IPv4 address to be used for IPv4 communication. shared (port-restricted) IPv4 address to be used for IPv4
Provisioning the lwB4 with its IPv4 address, port set and other communication. Provisioning the lwB4 with its IPv4 address, port set
parameters necessary for building the softwire is the core function and other parameters necessary for building the softwire is a core
of the Lightweight 4over6 control plane. function of the lw4o6 control plane.
[RFC7596] describes the use of DHCPv6 for deterministic IPv4 [RFC7596] describes the use of DHCPv6 for deterministic IPv4
provisioning. The IPv4 address, port set ID (PSID) and address of provisioning. The IPv4 address, port set ID (PSID) and address of
the lwAFTR are carried in DHCPv6 options defined in [RFC7598]. the lwAFTR are carried in DHCPv6 options defined in [RFC7598].
However, the deterministic provisioning of the IPv4 parameters However, the deterministic provisioning of the IPv4 parameters
imposes restrictions on the deployment: imposes restrictions on the deployment:
o The IPv4 address' life time is bound to the client's IPv6 tunnel o The IPv4 address' life time is bound to the client's IPv6 tunnel
endpoint life time endpoint life time
skipping to change at page 3, line 12 skipping to change at page 3, line 12
o The tunnel must be initiated from a fixed and predictable /64 o The tunnel must be initiated from a fixed and predictable /64
prefix in the home network topology prefix in the home network topology
o The IPv4 address and PSID need to be embedded into the IID of the o The IPv4 address and PSID need to be embedded into the IID of the
clients' /128 IPv6 address clients' /128 IPv6 address
o IPv4 address resources are permanently reserved for a client o IPv4 address resources are permanently reserved for a client
whether it is active or not. This results in less efficient whether it is active or not. This results in less efficient
public IPv4 address usage public IPv4 address usage
This document describes the deployment of Lightweight 4over6 using This document describes how lw4o6 uses DHCPv4 over DHCPv6 to achieve
DHCPv4 over DHCPv6 for dynamic IPv4 address provisioning. The main dynamic IPv4 address provisioning. The main advantages of using a
advantages of using a dynamic provisioning model over a deterministic dynamic provisioning model over a deterministic provisioning model
model are as follows: are as follows:
o No inherent restrictions on the IPv6 source address within the o No inherent restrictions on the IPv6 source address within the
customer internal network that the client uses for sourcing its customer internal network that the client uses for sourcing its
tunneled traffic tunneled traffic
o The lifetimes of IPv6 and IPv4 addresses are decoupled, allowing o The lifetimes of IPv6 and IPv4 addresses are decoupled, allowing
for more flexibility in the service provider's addressing policy for more flexibility in the service provider's addressing policy
o Inactive clients' addresses can be released/reclaimed for o Inactive clients' addresses can be released/reclaimed for
allocation to active clients, so more efficient address usage is allocation to active clients, so more efficient address usage is
possible possible
Since DHCPv4 over IPv4 cannot be used natively in a single stack IPv6 Since DHCPv4 over IPv4 cannot be used natively in a pure IPv6
network, DHCPv4 over DHCPv6 (DHCP4o6) [RFC7341] allows DHCPv4 network, DHCPv4 over DHCPv6 (DHCP 4o6) [RFC7341] allows DHCPv4
functionality to be trasported over a pure in IPv6 network by placing messages to be trasported over a pure IPv6 network by encapsulating
DHCPv4 messages within DHCPv6 messages. DHCPv4 messages into specific DHCPv6 options and messages.
[I-D.fsc-softwire-dhcp4o6-saddr-opt] defines a DHCP4o6 based Note that the dynamic provisioning decouples the IPv6 and IPv4
mechanism for the lwB4 to inform the server of its IPv6 tunnel source addresses, the binding info required by lwAFTR turns to be an
address. ayschronous combiantion of (restricted) IPv4 address and IPv6
address. [I-D.fsc-softwire-dhcp4o6-saddr-opt] defines a DHCP 4o6
based mechanism for the lwB4 to inform the server of its binding
between dynamically allocated IPv4 address and Port Set ID and the
IPv6 address that it will use for accessing IPv4-over-IPv6 services
The architecture which is described in this document can be The architecture which is described in this document can be
implemented with or without the sharing of IPv4 addresses between implemented with or without the sharing of IPv4 addresses between
multiple clients. If IPv4 address sharing is required, then multiple clients. If IPv4 address sharing is required, then
[RFC7618] describes the changes necessary extensions to the DHCPv4 [RFC7618] describes the necessary extensions to the DHCPv4 server and
server and client provisioning for the allocation and lease client provisioning for the allocation and lease management of shared
management of shared IPv4 addresses. IPv4 addresses.
2. Terminology 2. Terminology
Terminology defined in [RFC7341] and [RFC7596] is used extensively Terminology defined in [RFC7341] and [RFC7596] is used extensively
throughout this document. throughout this document.
Unless stated otherwise, the term "lwB4" should be understood to mean Determinstic provisioning: Lightweight B4 provisioning with DHCPv6 as
a stateful lwB4 using DHCP4o6 for dynamic IPv4 provisioning. described in section 5.1 of [RFC7596]. The IPv4 address, restricted
port set and the address of lwAFTR are carried in DHCPv6 options
defined in [RFC7598].
3. Architecture Overview Dynamic provisioning: Lightweight B4 provisioning with DHCPv4 over
DHCPv6 as described in this document. The IPv4 address and
rescricted port set are allocated through DHCP 4o6 transport as
defined in [RFC7341]. The allocation of lwAFTR's IPv6 address is
descirbed in [I-D.fsc-softwire-dhcp4o6-saddr-opt].
There are four functional elements which make up the architecture. 3. Dynamic Provisioning Model
Although these are shown as being seperate entities, it is possibile
that one or more of the operator side functions might be performed by As shown in Figure 1, the dynamic provisioning model consists of four
a single device. functional elements: lwB4, lwAFTR, DHCPv6 Server and DHCP 4o6 Server.
Note that these elements are not necessarily separate devices, one or
more functional elements could be located on a single device. One
existing example of this is the co-location of the DHCP 4o6 Server
and lwAFTR as a single gateway device. The differences in the
message flow from this co-location are also described below.
________ __________ ________ __________
| | | | | | | |
| DHCPv6 | | DHCP4o6 | | DHCPv6 | | DHCP 4o6 |
| Server | | Server | | Server | | Server |
|________| |__________| |________| |__________|
^ / \ ^ / \
1 | 2 / \ 3 1 | 2 / \ 3a/b
___v____ / \ ________ ___v____ / \ ________
| | | | | | | |
| lwB4 |<---------------->| lwAFTR | | lwB4 |<---------------->| lwAFTR |
|________| Data Plane |________| |________| Data Plane |________|
The numbers in each of the provisioning flows are described in more The numbers corresponding to each of the provisioning flows are
detail below. described in more detail below.
Figure 1: Dynamic lw4o6 Provisioning Model Figure 1: Dynamic lw4o6 Provisioning Model
The process for provisioning Lightweight 4over6 using DHCP4o6 is as 3.1. Flow 1: lwB4's IPv6 Addressing and DHCPv6 Configuration
follows:
1. The lwB4 uses DHCPv6[RFC3315] to obtain its basic configuration.
OPTION_DHCP4_O_DHCP6_SERVER (88) is included in the client's ORO.
The IPv6 address of at least one DHCP4o6 server is given in the
response.
2. The client sends a DHCPv4 DISCOVER message in a DHCP4o6 message Before attempting the DHCP 4o6 configuration process to obtain IPv4
to the DHCP4o6 server(s). The rest of the message flow proceeds configuration, the lwB4 requires an IPv6 address of a suitable scope
as per Section 5 of [I-D.fsc-softwire-dhcp4o6-saddr-opt]. The to allow communication with the lwAFTR (e.g. a link-local address
result is that the client is provisioned with the Ipv6 address of cannot be used). This IPv6 address can be configured using any
the lwAFTR, an IPv4 address and (optionally) a range of source applicable method (e.g. SLAAC, DHCPv6, etc.).
ports. The server has the /128 IPv6 address that the client will
use its tunnel source associated with the IPv4 lease.
3. lwAFTR binding table maintenance is achieved by using NETCONF To enable DHCPv4 over DHCPv6 transport, the lwB4 needs to perform
[RFC6241]. The YANG model for lw4o6 is defined in DHCPv6 to retrieve the DHCP 4o6 server's IPv6 address. The option
[I-D.sun-softwire-yang]. code OPTION_DHCP4_O_DHCP6_SERVER (88) is included in the client's
ORO. The DHCPv6 server responds the DHCP 4o6 server's IPv6 address
by carrying the addresses in DHCP 4o6 Server Address option as
defined in [RFC7341].
4. Lightweight4over6 Dynamic Provisioning Process 3.2. Flow 2: DHCP 4o6 Function
This section describes the dynamic provisioning process of Once the lwB4 has acquired the IPv6 address of the DHCP 4o6 server,
Lightweight 4over6 in more detail. stateful configuration using DHCP 4o6 is performed to obtain an IPv4
address and (optionally) a port set. The lwB4 sends a DHCPv4
DISCOVER message in a DHCPv4-query Message to the DHCP 4o6 server(s)
to activate the DHCP 4o6 transport. To obtain a shared IPv4 address,
the lwB4 also has to include Parameter Request List option with the
option code OPTION_V4_PORTPARAMS (159) as described in [RFC7618].
4.1. Client IPv6 Addressing To obtain the IPv6 address of lwAFTR and inform the DHCP4o6 server of
the lwB4's IPv6 tunnle source address, the message flow described in
section 5 of [I-D.fsc-softwire-dhcp4o6-saddr-opt] is followed by the
lwB4.
Before attempting the DHCP4o6 configuration process to obtain IPv4 Once successfully completed, the client has been provisioned with the
configuration, the lwB4 needs to have an IPv6 address of a suitable IPv6 address of the lwAFTR, an IPv4 address and (optionally) a range
scope to allow communication with the lwAFTR (e.g. a link-local of source ports. The server has the /128 IPv6 address that the
address cannot be used). There are no restrictions on how the client will use its tunnel source associated with the IPv4 lease.
client's IPv6 address is provisioned, (e.g. SLAAC, DHCPv6 or some
other mechanisms).
4.2. DHCPv6 Configuration 3.3. Flow 3: lwAFTR Binding Table Maintainence
The initial configuration step is for the lwB4 to perform DHCPv6 to As stated in [RFC7596], the lwAFTR MUST synchronize the binding
retrieve the DHCP 4o6 server's IPv6 address. The DHCPv6 server information with the port-restricted address provisioning process.
provides the DHCP 4o6 server's IPv6 address by In the dynamic provisioning model described in this document, once
OPTION_DHCP4_O_DHCP6_SERVER as defined in [RFC7341]. the lwB4's provisioning process is completed and the DHCP 4o6 server
holds the client's /128 IPv6 tunnel endpoint address, this binding
information can be syncronized with the lwAFTR. The method for this
synchronization is dependent on whether the DHCP 4o6 and lwAFTR
functions are co-located on the same physical host.
4.3. DHCPv4 over DHCPv6 Function 3.3.1. Flow 3a: Binding Table Maintenance for Co-located lwAFTR/DHCP
4o6 Functions
Once the lwB4 has acquired the IPv6 address of the DHCP4o6 server, Here, the lwAFTR maintains its binding table as per section 6.1 of
stateful configuration using DHCP4o6 is performed to obtain an IPv4 [RFC7596] and is synchronized with DHCP 4o6 process. The following
address and port set. The PSID is conveyed using DCHPv4 DHCP 4o6 messages trigger binding table modification:
OPTION_V4_PORTPARAMS (159) as decribed in [RFC7618]. The lwB4
includes one of its active IPv6 addresses as the IPv6 tunnel source
address in this message flow with the DHCP 4o6 server, and receives
the lwAFTR's tunnel address through DHCP4o6, as described in section
4 of [I-D.fsc-softwire-dhcp4o6-saddr-opt].
4.4. lwAFTR Binding Table Maintenance DHCPACK: Generated by the DHCP 4o6 server, triggers lwAFTR to add a
new entry or modify an existing entry.
In figure 1 above, the lwAFTR is not co-located with the DHCP 4o6 DHCPRELEASE: Generated by lwB4, triggers lwAFTR to delete an
server. With this architecture, NETCONF [RFC6241] is used for existing entry.
syncronising client DHCP4o6 provisioning and the lwAFTR binding
table. A YANG model for lw4o6 is defined in [I-D.sun-softwire-yang].
In this deployment model, the DHCP4o6 server and lwAFTR also
implements a NETCONF server. When an IPv4 leasing event occurs (e.g.
DHCPACK/DHCPRELEASE messages), the DHCP4o6 server informs the
operator's centralised configuration database of the change.
The operator's configuration database will then use NETCONF to update When the DHCP 4o6 server generates a DHCPACK message, information
the lwAFTR of the relevant change by adding or removing the binding about the new lease including the client's IPv6 tunnel endpoint
table entry which matches the DHCP4o6 server's IPv4 address lease. address and IPv4 address/PSID tuple is sent to the lwAFTR process.
The lwAFTR performs a check that this new binding does not match an
existing binding (both the v6 and v4 information must be checked
independently to ensure no conflicts). If no conflicts are found the
lwAFTR creates a new binding table entry for the client.
4.4.1. Co-located lwAFTR/DHCP4o6 Binding Table Maintenance If there an existing entry is found, the lwAFTR updates the IPv6
address and lifetime fields of the entry.
In this deployment scenario, the DHCP4o6 and lwAFTR functions are When the DHCP 4o6 server receives a DHCPRELEASE message, the lwAFTR
both active on the same device. Here, the lwAFTR maintains its looks up the binding table using the lwB4's IPv6 address, IPv4
binding table as per section 6.1 of [RFC7596] and is synchronized address and PSID as index. The lwAFTR deletes the entry either by
with DHCP4o6 process. The following DHCP4o6 messages trigger binding removing it from the binding table or by marking the lifetime field
table modification: with an invalid value (e.g. 0).
DHCPACK: Generated by the DHCP4o6 server, triggers lwAFTR to add a 3.3.2. Flow 3b: Binding Table Maintenance for Distributed lwAFTR/DHCP
new entry or modify an existing entry. 4o6 Functions
DHCPRELEASE: Generated by lwB4, triggers lwAFTR to delete an With this architecture, NETCONF [RFC6241] is used for syncronising
existing entry. client DHCP 4o6 provisioning and the lwAFTR binding table. A YANG
model for lw4o6 is defined in [I-D.sun-softwire-yang]. In this
deployment model, the DHCP 4o6 server and lwAFTR also implements a
NETCONF server. When an IPv4 leasing event occurs (DHCPACK/
DHCPRELEASE messages, or an active lease expiring), the DHCP 4o6
server informs the operator's centralised configuration database of
the change.
When the DHCP4o6 server generates a DHCPACK message, the lwAFTR looks The operator's configuration database will then use NETCONF to update
up the binding table using the lwB4's IPv4 address and PSID as index. the lwAFTR of the relevant change by adding or removing the binding
If there is an existing entry found, the lwAFTR updates the IPv6 table entry which matches he DHCP 4o6 server's IPv4 address lease.
address and lifetime fields of the entry; otherwise the lwAFTR
creates a new entry accordingly. When the DHCP4o6 server receives a
DHCPRELEASE message , the lwAFTR looks up the binding table using the
lwB4's IPv6 address, IPv4 address and PSID as index. The lwAFTR
deletes the entry either by removing it from the binding table or by
marking the lifetime field with an invalid value (e.g. 0).
5. Security Considerations 4. Security Considerations
Security considerations in [RFC7596] and [RFC7341] are also relevant Security considerations in [RFC7596] and [RFC7341] are also relevant
here. here.
The DHCP message triggered binding table maintenance may be used by The DHCP message triggered binding table maintenance may be used by
an attacker to send fake DHCP messages to lwAFTR. The operator an attacker to send fake DHCP messages to lwAFTR. The operator
network should deploy [RFC2827] to prevent this kind of attack. network should deploy [RFC2827] to prevent this kind of attack.
5.1. Data Retention Requirements 4.1. Data Retention Requirements
In some countries, regulations require a service providers to retain In some countries, regulations require a service providers to retain
the necessary information to link IP information to a specific the necessary information to link IP allocatoin information to a
customer. With a deterministic provisioning model, any individual specific customer at a specific point in time.
client will always receive a pre-determined set of IPv4 provisioning
With a deterministic provisioning model, any individual client will
always receive a pre-determined set of IPv4 provisioning
requirements. In this scenario, the logging requirement may be met requirements. In this scenario, the logging requirement may be met
by retaining information on how the DHCPv6 server has been pre- by retaining information on how the DHCPv6 server has been pre-
provisioned, with timestamp information on when changes to the pre- provisioned, with timestamp information on when changes to the pre-
provisioning have come into effect. provisioning have come into effect.
The dynamic provisioning model that is described in this document The dynamic provisioning model that is described in this document
brings an additional logging requirement to the service provider: The brings an additional logging requirement to the service provider: The
retention logs holding allocated IPv4 address and ports, the retention logs holding allocated IPv4 address and ports, the
associated IPv6 tunnel endpoint and timestamps marking the start and associated IPv6 tunnel endpoint and timestamps marking the start and
end of the lease. This is a higher logging overheard than end of the lease. This is a higher logging overheard than
deterministic provisioning, but is in line with the amount of logging deterministic provisioning, but is in line with the amount of logging
that service providers currently have. that service providers currently have.
6. IANA Considerations 5. IANA Considerations
This document does not include an IANA request. This document does not include an IANA request.
7. References 6. References
7.1. Normative References 6.1. Normative References
[I-D.fsc-softwire-dhcp4o6-saddr-opt] [I-D.fsc-softwire-dhcp4o6-saddr-opt]
Farrer, I., Sun, Q., and Y. Cui, "DHCPv4 over DHCPv6 Farrer, I., Sun, Q., and Y. Cui, "DHCPv4 over DHCPv6
Source Address Option", draft-fsc-softwire-dhcp4o6-saddr- Source Address Option", draft-fsc-softwire-dhcp4o6-saddr-
opt-04 (work in progress), November 2015. opt-04 (work in progress), November 2015.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <http://www.rfc-editor.org/info/rfc2827>. May 2000, <http://www.rfc-editor.org/info/rfc2827>.
skipping to change at page 7, line 41 skipping to change at page 8, line 5
[RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.
Farrer, "Lightweight 4over6: An Extension to the Dual- Farrer, "Lightweight 4over6: An Extension to the Dual-
Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596,
July 2015, <http://www.rfc-editor.org/info/rfc7596>. July 2015, <http://www.rfc-editor.org/info/rfc7596>.
[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>.
7.2. Informative References 6.2. Informative References
[I-D.sun-softwire-yang] [I-D.sun-softwire-yang]
Sun, Q., Wang, H., Cui, Y., Farrer, I., Boucadair, M., and Sun, Q., Wang, H., Cui, Y., Farrer, I., Boucadair, M., and
R. Asati, "YANG Data Model for IPv4-in-IPv6 Softwire", R. Asati, "YANG Data Model for IPv4-in-IPv6 Softwire",
draft-sun-softwire-yang-04 (work in progress), October draft-sun-softwire-yang-04 (work in progress), October
2015. 2015.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
 End of changes. 42 change blocks. 
130 lines changed or deleted 149 lines changed or added

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