draft-ietf-v6ops-siit-dc-02.txt   draft-ietf-v6ops-siit-dc-03.txt 
IPv6 Operations T. Anderson IPv6 Operations T. Anderson
Internet-Draft Redpill Linpro Internet-Draft Redpill Linpro
Intended status: Informational August 11, 2015 Intended status: Informational October 12, 2015
Expires: February 12, 2016 Expires: April 14, 2016
SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Centre Environments SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Centre Environments
draft-ietf-v6ops-siit-dc-02 draft-ietf-v6ops-siit-dc-03
Abstract Abstract
This document describes the use of the Stateless IP/ICMP Translation This document describes the use of the Stateless IP/ICMP Translation
(SIIT) algorithm in an IPv6 Internet Data Centre (IDC). In this (SIIT) algorithm in an IPv6 Internet Data Centre (IDC). In this
deployment model, traffic from legacy IPv4-only clients on the deployment model, traffic from legacy IPv4-only clients on the
Internet is translated to IPv6 upon reaching the IDC operator's Internet is translated to IPv6 upon reaching the IDC operator's
network infrastructure. From that point on, it may be treated the network infrastructure. From that point on, it may be treated the
same as traffic from native IPv6 end users. The IPv6 endpoints may same as traffic from native IPv6 end users. The IPv6 endpoints may
be numbered using arbitrary (non-IPv4-translatable) IPv6 addresses. be numbered using arbitrary (non-IPv4-translatable) IPv6 addresses.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 12, 2016. This Internet-Draft will expire on April 14, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 23 skipping to change at page 2, line 23
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. Single Stack IPv6 Operation . . . . . . . . . . . . . . . 3 1.1. Single Stack IPv6 Operation . . . . . . . . . . . . . . . 3
1.2. Stateless Operation . . . . . . . . . . . . . . . . . . . 4 1.2. Stateless Operation . . . . . . . . . . . . . . . . . . . 4
1.3. IPv4 Address Conservation . . . . . . . . . . . . . . . . 4 1.3. IPv4 Address Conservation . . . . . . . . . . . . . . . . 4
1.4. Clients' IPv4 Source Addresses Visible to Applications . 5 1.4. Clients' IPv4 Source Addresses Visible to Applications . 5
1.5. Compatible with Standard IPv4 and IPv6 Stacks . . . . . . 5 1.5. Compatible with Standard IPv4 and IPv6 Stacks . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Architectural Overview . . . . . . . . . . . . . . . . . . . 7 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 7
3.1. Packet Flow . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Packet Flow . . . . . . . . . . . . . . . . . . . . . . . 9
4. Deployment Considerations and Guidelines . . . . . . . . . . 10 4. Deployment Considerations and Guidelines . . . . . . . . . . 10
4.1. Application/Device Support for IPv6 . . . . . . . . . . . 10 4.1. Application/Device Support for IPv6 . . . . . . . . . . . 10
4.2. Application Support for NAT . . . . . . . . . . . . . . . 10 4.2. Application Support for NAT . . . . . . . . . . . . . . . 10
4.3. Application Communication Pattern . . . . . . . . . . . . 10 4.3. Application Communication Pattern . . . . . . . . . . . . 10
4.4. Choice of Translation Prefix . . . . . . . . . . . . . . 11 4.4. Choice of Translation Prefix . . . . . . . . . . . . . . 11
4.5. Routing Considerations . . . . . . . . . . . . . . . . . 12 4.5. Routing Considerations . . . . . . . . . . . . . . . . . 12
4.6. Location of the SIIT-DC Border Relays . . . . . . . . . . 12 4.6. Location of the SIIT-DC Border Relays . . . . . . . . . . 12
4.7. Migration from Dual Stack . . . . . . . . . . . . . . . . 13 4.7. Migration from Dual Stack . . . . . . . . . . . . . . . . 12
4.8. Translation of ICMPv6 Errors to IPv4 . . . . . . . . . . 13 4.8. Translation of ICMPv6 Errors to IPv4 . . . . . . . . . . 13
4.9. MTU and Fragmentation . . . . . . . . . . . . . . . . . . 13 4.9. MTU and Fragmentation . . . . . . . . . . . . . . . . . . 13
4.9.1. IPv4/IPv6 Header Size Difference . . . . . . . . . . 14 4.9.1. IPv4/IPv6 Header Size Difference . . . . . . . . . . 13
4.9.2. IPv6 Atomic Fragments . . . . . . . . . . . . . . . . 14 4.9.2. IPv6 Atomic Fragments . . . . . . . . . . . . . . . . 14
4.9.3. Minimum Path MTU Difference Between IPv4 and IPv6 . . 15 4.9.3. Minimum Path MTU Difference Between IPv4 and IPv6 . . 15
4.10. IPv4-translatable IPv6 Service Addresses . . . . . . . . 16 4.10. IPv4-translatable IPv6 Service Addresses . . . . . . . . 16
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7.1. Mistaking the Translation Prefix for a Trusted Network . 17 7.1. Mistaking the Translation Prefix for a Trusted Network . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . 18
skipping to change at page 3, line 27 skipping to change at page 3, line 27
they only need to operate one protocol in the data centre as they they only need to operate one protocol in the data centre as they
prepare for the future. SIIT-DC is one such approach. Its design prepare for the future. SIIT-DC is one such approach. Its design
goals include: goals include:
o Promote the deployment of native IPv6 services (cf. [RFC6540]). o Promote the deployment of native IPv6 services (cf. [RFC6540]).
o Provide IPv4 service availability for legacy users with no loss of o Provide IPv4 service availability for legacy users with no loss of
performance or functionality. performance or functionality.
o To ensure that that the legacy users' IPv4 addresses remain o To ensure that that the legacy users' IPv4 addresses remain
visible to the nodes and applications. visible to the nodes and applications located in the IPv6 network.
o To conserve and maximise the utilisation of the operator's public o To conserve and maximise the utilisation of the operator's public
IPv4 addresses. IPv4 addresses.
o To avoid introducing more complexity than absolutely necessary, o To avoid introducing more complexity than absolutely necessary,
especially on the nodes and applications. especially on the nodes and applications.
o To be easy to scale and deploy in a fault-tolerant manner. o To be easy to scale and deploy in a fault-tolerant manner.
The following subsections elaborates on how SIIT-DC meets these The following subsections elaborates on how SIIT-DC meets these
skipping to change at page 4, line 9 skipping to change at page 4, line 9
the IDC operator's services and applications. the IDC operator's services and applications.
SIIT-DC requires no special support or change from the underlying SIIT-DC requires no special support or change from the underlying
IPv6 infrastructure, it is compatible with all standard IPv6 IPv6 infrastructure, it is compatible with all standard IPv6
networks. Traffic between IPv6-enabled end users and IPv6-enabled networks. Traffic between IPv6-enabled end users and IPv6-enabled
services will always be transported native end-to-end; SIIT-DC does services will always be transported native end-to-end; SIIT-DC does
not intercept or handle native IPv6 traffic at all. not intercept or handle native IPv6 traffic at all.
When the day comes to discontinue all support for IPv4, no change When the day comes to discontinue all support for IPv4, no change
needs to be made to the overall architecture - it's only a matter of needs to be made to the overall architecture - it's only a matter of
shutting off the BRs. Operators who deploy native IPv6 along with shutting off the SIIT-DC Border Relays (BRs). Operators who deploy
SIIT-DC will thus avoid requiring any future migration or deployment native IPv6 along with SIIT-DC will thus avoid requiring any future
projects relating to IPv6 deployment and/or IPv4 sun-setting. migration or deployment projects relating to IPv6 deployment and/or
IPv4 sun-setting.
1.2. Stateless Operation 1.2. Stateless Operation
Unlike other solutions that provide either dual stack availability to Unlike other solutions that provide either dual stack availability to
single-stack services (e.g., Stateful NAT64 [RFC6146] and Layer-4/7 single-stack services (e.g., Stateful NAT64 [RFC6146] and Layer-4/7
proxies), or that provide conservation of IPv4 addresses (e.g., proxies), or that provide conservation of IPv4 addresses (e.g.,
NAPT44 [RFC3022]), SIIT-DC does not keep any state between each NAPT44 [RFC3022]), SIIT-DC does not maintain any state associated
packet in a single connection or flow. In this sense it operates with individual connections or flows. In this sense it operates
exactly like a regular IP router, and has similar scaling properties exactly like a regular IP router, and has similar scaling properties
- the limiting factors are packets per second and bandwidth. The - the limiting factors are packets per second and bandwidth. The
number of concurrent flows and flow initiation rates are irrelevant number of concurrent flows and flow initiation rates are irrelevant
for performance. for performance.
This not only allows individual BRs to easily attain "line rate" This not only allows individual BRs to easily attain "line rate"
performance, it also allows for per-packet load balancing between performance, it also allows for per-packet load balancing between
multiple BRs using Equal-Cost Multipath Routing [RFC2991]. multiple BRs using Equal-Cost Multipath Routing [RFC2991].
Asymmetric routing is also acceptable, which makes it easy to avoid Asymmetric routing is also acceptable, which makes it easy to avoid
sub-optimal traffic patterns; the prefixes involved may be anycasted sub-optimal traffic patterns; the prefixes involved may be anycasted
skipping to change at page 5, line 20 skipping to change at page 5, line 12
suitable block for sale can be located, and/or turn out to be suitable block for sale can be located, and/or turn out to be
prohibitively expensive. In spite of this, an IDC operator will find prohibitively expensive. In spite of this, an IDC operator will find
that providing IPv4 service remains essential, as a large share of that providing IPv4 service remains essential, as a large share of
the Internet end users still do not have IPv6 connectivity. the Internet end users still do not have IPv6 connectivity.
A key goal of SIIT-DC is to help reduce a data centre operator's IPv4 A key goal of SIIT-DC is to help reduce a data centre operator's IPv4
address requirement to the absolute minimum, by allowing the operator address requirement to the absolute minimum, by allowing the operator
to remove them entirely from nodes and applications that do not need to remove them entirely from nodes and applications that do not need
to communicate with endpoints in the IPv4 Internet. One example to communicate with endpoints in the IPv4 Internet. One example
would be servers that are operating in a supporting/back-end role and would be servers that are operating in a supporting/back-end role and
only communicates with to other servers (database servers, file only communicates with other servers (database servers, file servers,
servers, and so on). Another example would be the network and so on). Another example would be the network infrastructure
infrastructure itself (router-to-router links, loopback addresses, itself (router-to-router links, loopback addresses, and so on).
and so on). Furthermore, as LAN prefix sizes must always be rounded Furthermore, as LAN prefix sizes must always be rounded up to the
up to the nearest power of two (or larger, if one reserves space for nearest power of two (or larger, if one reserves space for future
future growth), even more IPv4 addresses will often end up being growth), even more IPv4 addresses will often end up being wasted
wasted without even being used. without even being used.
With SIIT-DC, the operator can remove these valuable IPv4 addresses With SIIT-DC, the operator can remove these valuable IPv4 addresses
from his back-end servers and network infrastructure, and reassign from his back-end servers and network infrastructure, and reassign
them to the SIIT-DC service as IPv4 Service Addresses. There exists them to the SIIT-DC service as IPv4 Service Addresses. There exists
no requirement that IPv4 Service Addresses are assigned in an no requirement that IPv4 Service Addresses are assigned in an
aggregated manner, so there is nothing lost due to infrastructure aggregated manner, so there is nothing lost due to infrastructure
overhead; every single IPv4 address assigned to SIIT-DC can be used overhead; every single IPv4 address assigned to SIIT-DC can be used
an IPv4 Service Address. an IPv4 Service Address.
1.4. Clients' IPv4 Source Addresses Visible to Applications 1.4. Clients' IPv4 Source Addresses Visible to Applications
SIIT-DC uses the [RFC6052] algorithm to map the entire end-user's SIIT-DC uses the [RFC6052] algorithm to map the entire end-user's
IPv4 source address into an predefined IPv6 Translation Prefix. This IPv4 source address into an predefined IPv6 Translation Prefix. This
ensures that there is no loss of information; the end-user's IPv4 ensures that there is no loss of information; the end-user's IPv4
source address remains available to the application, allowing it to source address remains available to the application located in the
perform tasks like Geo-Location, logging, abuse handling, and so IPv6 network, allowing it to perform tasks like Geo-Location,
forth. logging, abuse handling, and so forth.
1.5. Compatible with Standard IPv4 and IPv6 Stacks 1.5. Compatible with Standard IPv4 and IPv6 Stacks
Except for the introduction of the BRs themselves, no change to the Except for the introduction of the BRs themselves, no change to the
network, nodes, applications, or anything else is required in order network, nodes, applications, or anything else is required in order
to support SIIT-DC. SIIT-DC is practically invisible from the point to support SIIT-DC. SIIT-DC is practically invisible from the point
of view of the IPv4 clients, the IPv6 nodes, the IPv6 data centre of view of the IPv4 clients, the IPv6 nodes, the IPv6 data centre
network, and the IPv4 Internet. SIIT-DC interoperates with all network, and the IPv4 Internet. SIIT-DC interoperates with all
standards-compliant IPv4 or IPv6 stacks. standards-compliant IPv4 or IPv6 stacks.
2. Terminology 2. Terminology
This document makes use of the following terms: This document makes use of the following terms:
skipping to change at page 6, line 17 skipping to change at page 6, line 5
of view of the IPv4 clients, the IPv6 nodes, the IPv6 data centre of view of the IPv4 clients, the IPv6 nodes, the IPv6 data centre
network, and the IPv4 Internet. SIIT-DC interoperates with all network, and the IPv4 Internet. SIIT-DC interoperates with all
standards-compliant IPv4 or IPv6 stacks. standards-compliant IPv4 or IPv6 stacks.
2. Terminology 2. Terminology
This document makes use of the following terms: This document makes use of the following terms:
SIIT-DC Border Relay (BR) SIIT-DC Border Relay (BR)
A device or a logical function that performs stateless protocol A device or a logical function that performs stateless protocol
translation between IPv4 and IPv6 in accordance with [RFC6145] and translation between IPv4 and IPv6. It MUST do so in accordance
[I-D.ietf-v6ops-siit-eam]. with [RFC6145] and [I-D.ietf-v6ops-siit-eam].
SIIT-DC Edge Relay (ER) SIIT-DC Edge Relay (ER)
A device or logical function that provides "native" IPv4 A device or logical function that provides "native" IPv4
connectivity to IPv4-only devices or application software. It is connectivity to IPv4-only devices or application software. It is
very similar in function to a BR, but is typically located close very similar in function to a BR, but is typically located close
to the IPv4-only component(s) it is supporting rather than on the to the IPv4-only component(s) it is supporting rather than on the
IDC's outer network border. The ERs is an optional component of IDC's outer network border. The ER is an optional component of
SIIT-DC. It is discussed in more detail in SIIT-DC. It is discussed in more detail in
[I-D.ietf-v6ops-siit-dc-2xlat]. [I-D.ietf-v6ops-siit-dc-2xlat].
IPv4 Service Address IPv4 Service Address
A public IPv4 address with which IPv4-only clients communicates. An IPv4 address representing a node or service located in an IPv6
This communication will be translated to IPv6 by a BR. The network. It is coupled with an IPv6 Service Address using an EAM.
service's "IN A" DNS record will typically point to the IPv4 Packets sent to this address is translated to IPv6 by the BR, and
Service Address. possibly back to IPv4 by an ER, before reaching the node or
service.
IPv4 Service Address Pool IPv4 Service Address Pool
One or more IPv4 prefixes routed to the BR's IPv4 interface. IPv4 One or more IPv4 prefixes routed to the BR's IPv4 interface. IPv4
Service Addresses are allocated from this pool. That this does Service Addresses are allocated from this pool. That this does
not necessarily have to be a "pool" per se, as it could also be not necessarily have to be a "pool" per se, as it could also be
one or more host routes (whose prefix length is equal to /32). one or more host routes (whose prefix length is equal to /32).
The purpose of using a pool rather than host routes is to The purpose of using a pool rather than host routes is to
facilitate IPv4 route aggregation and ease provisioning of new facilitate IPv4 route aggregation and ease provisioning of new
IPv4 Service Addresses. IPv4 Service Addresses.
IPv6 Service Address IPv6 Service Address
A public IPv6 address assigned to a node (such as a server or An IPv6 address assigned to an application, node, or service;
load-balancer) or an individual application in the IPv6 network. either directly or indirectly (through an ER). It is coupled with
IPv6-capable clients communicate directly with the IPv6 Service an IPv4 Service Address using an EAM. IPv4-only clients
Address using native IPv6. The service's "IN AAAA" DNS record communicates with the IPv6 Service Address through SIIT-DC.
will typically point to the IPv6 Service Address. IPv4-only
clients indirectly communicate with the IPv6 Service Address
through SIIT-DC.
Explicit Address Mapping (EAM) Explicit Address Mapping (EAM)
A bi-directional coupling between an IPv4 Service Address and an A bi-directional coupling between an IPv4 Service Address and an
IPv6 Service Address configured in a BR or ER. When translating IPv6 Service Address configured in a BR or ER. When translating
between IPv4 and IPv6, the BR/ER changes the address fields in the between IPv4 and IPv6, the BR/ER changes the address fields in the
translated packet's IP header according to any matching EAM. See translated packet's IP header according to any matching EAM. The
[I-D.ietf-v6ops-siit-eam]. EAM algorithm is specified in [I-D.ietf-v6ops-siit-eam].
Translation Prefix Translation Prefix
An IPv6 prefix into which the entire IPv4 address space is mapped. An IPv6 prefix into which the entire IPv4 address space is mapped,
This prefix is routed to the BR's IPv6 interface. It is either a according to the algorithm in [RFC6052]. The Translation Prefix
Network-Specific Prefix or the Well-Known Prefix 64:ff9b::/96, cf. is routed to the BR's IPv6 interface. When translating between
[RFC6052]. When translating between IPv4 and IPv6, a BR/ER IPv4 and IPv6, an BR/ER will insert/remove the Translation Prefix
inserts or removes the Translation Prefix from the address fields into/from the address fields in the translated packet's IP header,
in the translated packet's IP header, unless an EAM for the IP unless an EAM exists for the IP address that is being translated.
address being translated exists.
IPv4-translatable IPv6 addresses IPv4-translatable IPv6 addresses
As defined in Section 1.3 of [RFC6052]. As defined in Section 1.3 of [RFC6052].
IDC IDC
Short for "Internet Data Centre"; a data centre whose main purpose Short for "Internet Data Centre"; a data centre whose main purpose
is to deliver services to the public Internet, the use case SIIT- is to deliver services to the public Internet, the use case SIIT-
DC is primarily targeted at. IDCs are typically operated by DC is primarily targeted at. IDCs are typically operated by
Internet Content Providers or Managed Services Providers. Internet Content Providers or Managed Services Providers.
SIIT SIIT
The Stateless IP/ICMP Translation algorithm, as specified in The Stateless IP/ICMP Translation algorithm, as specified in
[RFC6145]. [RFC6145].
XLAT XLAT
Short for "translation". Short for "Translation". Used in figures to indicate where a BR/
ER uses SIIT [RFC6145] to translate IPv4 packets to IPv6 and vice
versa.
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 [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Architectural Overview 3. Architectural Overview
This section describes the basic SIIT-DC architecture. This section describes the basic SIIT-DC architecture.
SIIT-DC Architecture SIIT-DC Architecture
skipping to change at page 8, line 41 skipping to change at page 8, line 41
traffic destined for it is routed to the BR's IPv4-facing network traffic destined for it is routed to the BR's IPv4-facing network
interface. There are no restrictions on how many IPv4 Service interface. There are no restrictions on how many IPv4 Service
Address Pools are used or their prefix length, as long as they are Address Pools are used or their prefix length, as long as they are
all routed to the BR's IPv4-facing network interface. all routed to the BR's IPv4-facing network interface.
When translating packets between IPv4 and IPv6, the BR uses the EAM When translating packets between IPv4 and IPv6, the BR uses the EAM
to replace any occurrence of the IPv4 Service Address (192.0.2.1) to replace any occurrence of the IPv4 Service Address (192.0.2.1)
with its corresponding IPv6 Service Address (2001:db8:12:34::1). with its corresponding IPv6 Service Address (2001:db8:12:34::1).
Addresses that do not match any EAM configured in the BR are Addresses that do not match any EAM configured in the BR are
translated by inserting or removing the Translation Prefix translated by inserting or removing the Translation Prefix
(2001:db8:46::/96), cf. Section 2.2 of RFC6052 [RFC6052]. (2001:db8:46::/96), cf. Section 2.2 of [RFC6052].
The BR can be deployed as a separate device or as a logical function The BR can be deployed as a separate device or as a logical function
in another multi-purpose device, such as an IP router. Any number of in another multi-purpose device, such as an IP router. Any number of
BRs may exist simultaneously in the IDC's network infrastructure, as BRs may exist simultaneously in the IDC's network infrastructure, as
long as they all configured with the same Translation Prefix and an long as they all configured with the same Translation Prefix and an
identical EAM Table. identical EAM Table.
The IPv6 Service Address of should be registered in DNS using an "IN The IPv6 Service Address of should be registered in DNS using an "IN
AAAA" record, while its corresponding IPv4 Service Address should be AAAA" record, while its corresponding IPv4 Service Address should be
registered using an "IN A" record. This ensures that IPv6-capable registered using an "IN A" record. This ensures that IPv6-capable
skipping to change at page 10, line 12 skipping to change at page 10, line 12
perform IPv4-specific tasks such as Geo-Location, logging, abuse perform IPv4-specific tasks such as Geo-Location, logging, abuse
handling, and so on. handling, and so on.
4. Deployment Considerations and Guidelines 4. Deployment Considerations and Guidelines
4.1. Application/Device Support for IPv6 4.1. Application/Device Support for IPv6
SIIT-DC as described in this document requires that the application SIIT-DC as described in this document requires that the application
(and/or the node the application is located on) supports IPv6 (and/or the node the application is located on) supports IPv6
networking, and that it has no dependency on local IPv4 network networking, and that it has no dependency on local IPv4 network
connectivity. However, SIIT-DC supports IPv4-dependent applications connectivity.
and nodes through the introduction of an ER. The ER provides the
application or node with seemingly native IPv4 connectivity, by SIIT-DC can however support legacy IPv4-dependent applications and
translating the packets (that were previously translated from IPv4 to nodes through the introduction of an ER. The ER provides the legacy
IPv6) by the BR back to IPv4 before passing them to the application or node with seemingly native IPv4 Internet connectivity,
IPv4-dependent application or node. This approach is described in so that it may operate correctly in an otherwise IPv6-only network
more detail in [I-D.ietf-v6ops-siit-dc-2xlat]. environment. This approach is described in more detail in
[I-D.ietf-v6ops-siit-dc-2xlat].
4.2. Application Support for NAT 4.2. Application Support for NAT
The operator should carefully examine whether or not the application The operator should carefully examine whether or not the application
protocols he would like to use SIIT-DC with are able to operate in a protocols he would like to use SIIT-DC with are able to operate in a
network environment where rewriting of IP addresses occur. In network environment where rewriting of IP addresses occur. In
general, if an application layer protocol works correctly through general, if an application layer protocol works correctly through
standard NAT44 (see [RFC3235]), it will most likely work correctly standard NAT44 (see [RFC3235]), it will most likely work correctly
through SIIT-DC as well. through SIIT-DC as well.
skipping to change at page 11, line 37 skipping to change at page 11, line 38
another translation technology such as Stateful NAT64 [RFC6146], the another translation technology such as Stateful NAT64 [RFC6146], the
operator will be forced to use an NSP for all but one of those operator will be forced to use an NSP for all but one of those
deployments. deployments.
Another consideration is that the WKP cannot be used in inter-domain Another consideration is that the WKP cannot be used in inter-domain
routing. By using an NSP instead, SIIT-DC will support a deployment routing. By using an NSP instead, SIIT-DC will support a deployment
where the BR and the IPv6 Service Address are located in different where the BR and the IPv6 Service Address are located in different
Autonomous Systems. Autonomous Systems.
The Translation Prefix may use any of the lengths described in The Translation Prefix may use any of the lengths described in
Section 2.2 of RFC6052 [RFC6052], but /96 has two distinct advantages Section 2.2 of [RFC6052], but /96 has two distinct advantages over
over the others. First, converting it to IPv4 can be done in a the others. First, converting it to IPv4 can be done in a single
single operation by simply stripping off the first 96 bits; second, operation by simply stripping off the first 96 bits; second, it
it allows for IPv4 addresses to be embedded directly into the text allows for IPv4 addresses to be embedded directly into the text
representation of an IPv6 address using the familiar dotted quad representation of an IPv6 address using the familiar dotted quad
notation, e.g., "2001:db8::198.51.100.10" (cf. Section 2.4 of RFC6052 notation, e.g., "2001:db8::198.51.100.10" (cf. Section 2.4 of
[RFC6052])), instead of being converted to hexadecimal notation. [RFC6052])), instead of being converted to hexadecimal notation.
This makes it easier to write IPv6 ACLs and similar that match This makes it easier to write IPv6 ACLs and similar that match
translated endpoints in the IPv4 Internet. translated endpoints in the IPv4 Internet.
For the reasons discussed above, this document recommends that an NSP For the reasons discussed above, this document recommends that an NSP
with a prefix length of /96 is used. Section 3.3 of [RFC6052] with a prefix length of /96 is used. Section 3.3 of [RFC6052]
discusses the choice of translation prefix in more detail. discusses the choice of translation prefix in more detail.
4.5. Routing Considerations 4.5. Routing Considerations
skipping to change at page 12, line 24 skipping to change at page 12, line 24
providing high availability: Should one BR fail, the IGP will providing high availability: Should one BR fail, the IGP will
automatically redirect the traffic to the closest alternate BR. automatically redirect the traffic to the closest alternate BR.
4.6. Location of the SIIT-DC Border Relays 4.6. Location of the SIIT-DC Border Relays
The goal of SIIT-DC is to facilitate a true IPv6-only application and The goal of SIIT-DC is to facilitate a true IPv6-only application and
network architecture, with the sole exception being the IPv4 network architecture, with the sole exception being the IPv4
interfaces of the BRs and the network infrastructure required to interfaces of the BRs and the network infrastructure required to
connect the BRs to the IPv4 Internet. Therefore, the BRs must be connect the BRs to the IPv4 Internet. Therefore, the BRs must be
located somewhere between the IPv4 Internet and the application located somewhere between the IPv4 Internet and the application
delivery stack. This should be understood to include all servers, delivery stack - which includes all servers, load balancers,
load balancers, firewalls, intrusion detection systems, and similar firewalls, intrusion detection systems, and similar devices that are
devices that are processing traffic to a greater extent than merely processing traffic to a greater extent than merely forwarding it.
forwarding it.
It is optimal to place the BRs as close as possible to the direct It is optimal to place the BRs as close as possible to the direct
path between the location of the IPv6 Service Address and the end path between the location of the IPv6 Service Address and the end
users. If the closest BR was located a long way from the direct users. If the closest BR was located a long way from the direct
path, all packets in both directions must make a detour in order to path, all packets in both directions must make a detour in order to
traverse the BR. This would increase the RTT between the service and traverse the BR. This would increase the RTT between the service and
the end user by by two times the extra latency incurred by the the end user by by two times the extra latency incurred by the
detour, as well as cause unnecessary load on the network links on the detour, as well as cause unnecessary load on the network links on the
detour path. detour path.
skipping to change at page 13, line 39 skipping to change at page 13, line 36
the ICMPv6 error happens to be a IPv4-translatable IPv6 address or the ICMPv6 error happens to be a IPv4-translatable IPv6 address or
covered by an EAM. covered by an EAM.
To facilitate reliable delivery of such ICMPv6 errors, an SIIT-DC To facilitate reliable delivery of such ICMPv6 errors, an SIIT-DC
operator SHOULD implement the recommendations in [RFC6791] in the operator SHOULD implement the recommendations in [RFC6791] in the
BRs. BRs.
4.9. MTU and Fragmentation 4.9. MTU and Fragmentation
There are some key differences between IPv4 and IPv6 relating to There are some key differences between IPv4 and IPv6 relating to
packet sizes and fragmentation that one should consider when packet sizes and fragmentation that one MUST consider when deploying
deploying SIIT-DC. They result in a few problematic corner cases, SIIT-DC. They result in a few problematic corner cases, which can be
which can be dealt with in a few different ways. The following dealt with in a few different ways. The following subsections will
subsections will discuss these in detail, and provide operational discuss these in detail, and provide operational guidance.
guidance.
In particular, the operator may find that relying on fragmentation in In particular, the operator may find that relying on fragmentation in
the IPv6 domain is undesired or even operationally impossible the IPv6 domain is undesired or even operationally impossible
[I-D.taylor-v6ops-fragdrop]. For this reason, the recommendations in [I-D.taylor-v6ops-fragdrop]. For this reason, the recommendations in
this section seeks to minimise the use of IPv6 fragmentation. this section seeks to minimise the use of IPv6 fragmentation.
Unless otherwise stated, the following subsections assume that the Unless otherwise stated, the following subsections assume that the
MTU in both the IPv4 and IPv6 domains is 1500 bytes. MTU in both the IPv4 and IPv6 domains is 1500 bytes.
4.9.1. IPv4/IPv6 Header Size Difference 4.9.1. IPv4/IPv6 Header Size Difference
skipping to change at page 14, line 32 skipping to change at page 14, line 29
themselves SHOULD NOT be increased accordingly, as doing so would themselves SHOULD NOT be increased accordingly, as doing so would
cause them to undergo Path MTU Discovery for all destinations on the cause them to undergo Path MTU Discovery for all destinations on the
IPv6 Internet. The nodes MUST however be able to accept and process IPv6 Internet. The nodes MUST however be able to accept and process
incoming packets larger than their own MTU. If the nodes' IPv6 incoming packets larger than their own MTU. If the nodes' IPv6
implementation allows the initial Path MTU to be set differently for implementation allows the initial Path MTU to be set differently for
specific destinations, it MAY be increased to 1520 for destinations specific destinations, it MAY be increased to 1520 for destinations
within the Translation Prefix specifically. within the Translation Prefix specifically.
4.9.2. IPv6 Atomic Fragments 4.9.2. IPv6 Atomic Fragments
In keeping with the fifth paragraph of Section 4 of RFC6145 In keeping with the fifth paragraph of Section 4 of [RFC6145], a
[RFC6145], a stateless translator like a BR will by default add an stateless translator like a BR will by default add an IPv6
IPv6 Fragmentation header to the resulting IPv6 packet when Fragmentation header to the resulting IPv6 packet when translating an
translating an IPv4 packet with the Don't Fragment flag set to 0. IPv4 packet with the Don't Fragment flag set to 0. This happens even
This happens even though the resulting IPv6 packet isn't actually though the resulting IPv6 packet isn't actually fragmented into
fragmented into several pieces, resulting in an IPv6 Atomic Fragment several pieces, resulting in an IPv6 Atomic Fragment [RFC6946].
[RFC6946]. These Atomic Fragments are generally not useful in an IDC These Atomic Fragments are generally not useful in an IDC
environment, and it is therefore recommended that this behaviour is environment, and it is therefore recommended that this behaviour is
disabled in the BRs. To this end, Section 4 of RFC6145 [RFC6145] disabled in the BRs. To this end, Section 4 of [RFC6145] notes that
notes that the "translator MAY provide a configuration function that the "translator MAY provide a configuration function that allows the
allows the translator not to include the Fragment Header for the non- translator not to include the Fragment Header for the non-fragmented
fragmented IPv6 packets". IPv6 packets".
Note that IPv6 Atomic Fragments are currently being deprecated by Note that IPv6 Atomic Fragments are currently being deprecated by
RFC6145bis [I-D.bao-v6ops-rfc6145bis]. As a result, a BR that RFC6145bis [I-D.bao-v6ops-rfc6145bis]. As a result, a BR that
conforms to the updated standard is required to behave as recommended conforms to the updated standard is required to behave as recommended
above. above.
In IPv6, the Identification value is located inside the Fragmentation In IPv6, the Identification value is located inside the Fragmentation
header. That means that if the generation of IPv6 Atomic Fragments header. That means that if the generation of IPv6 Atomic Fragments
is disabled, the IPv4 Identification value will be lost during is disabled, the IPv4 Identification value will be lost during
translation to IPv6. This could potentially confuse some diagnostic translation to IPv6. This could potentially confuse some diagnostic
tools. tools.
4.9.3. Minimum Path MTU Difference Between IPv4 and IPv6 4.9.3. Minimum Path MTU Difference Between IPv4 and IPv6
Section 5 of RFC2460 [RFC2460] specifies that the minimum IPv6 link Section 5 of [RFC2460] specifies that the minimum IPv6 link MTU is
MTU is 1280 bytes. Therefore, an IPv6 node can reasonably assume 1280 bytes. Therefore, an IPv6 node can reasonably assume that if it
that if it transmits an IPv6 packet that is 1280 bytes or smaller, it transmits an IPv6 packet that is 1280 bytes or smaller, it is
is guaranteed to reach its destination without requiring guaranteed to reach its destination without requiring fragmentation
fragmentation or invoking the Path MTU Discovery algorithm [RFC1981]. or invoking the Path MTU Discovery algorithm [RFC1981]. However,
However, this assumption might prove false if the destination is an this assumption might prove false if the destination is an IPv4 node
IPv4 node reached through a protocol translator such as a BR, as the reached through a protocol translator such as a BR, as the minimum
minimum IPv4 link MTU is 68 bytes. See Section 3.2 of RFC791 IPv4 link MTU is 68 bytes. See Section 3.2 of [RFC0791].
[RFC0791].
Section 5.1 of RFC6145 [RFC6145] specifies that a stateless Section 5.1 of [RFC6145] specifies that a stateless translator should
translator should set the IPv4 Don't Fragment flag to 1 when it set the IPv4 Don't Fragment flag to 1 when it translates a non-
translates a non-fragmented IPv6 packet to IPv4. This means that fragmented IPv6 packet to IPv4. This means that when the path to the
when the path to the destination IPv4 node contains an IPv4 link with destination IPv4 node contains an IPv4 link with an MTU smaller than
an MTU smaller than 1260 bytes (which corresponds to an IPv6 MTU 1260 bytes (which corresponds to an IPv6 MTU smaller than 1280 bytes,
smaller than 1280 bytes, cf. Section 4.9.1), the Path MTU Discovery cf. Section 4.9.1), the Path MTU Discovery algorithm will be invoked,
algorithm will be invoked, even if the original IPv6 packet was only even if the original IPv6 packet was only 1280 bytes large. This
1280 bytes large. This happens as a result of the IPv4 router happens as a result of the IPv4 router connecting to the IPv4 link
connecting to the IPv4 link with the small MTU returning an ICMPv4 with the small MTU returning an ICMPv4 Need To Fragment error with an
Need To Fragment error with an MTU value smaller than 1260, which in MTU value smaller than 1260, which in turns is translated by the BR
turns is translated by the BR to an ICMPv6 Packet Too Big error with to an ICMPv6 Packet Too Big error with an MTU value smaller than 1280
an MTU value smaller than 1280 which is then transmitted to the which is then transmitted to the origin IPv6 node.
origin IPv6 node.
When an IPv6 node receives an ICMPv6 Packet Too Big error indicating When an IPv6 node receives an ICMPv6 Packet Too Big error indicating
an MTU value smaller than 1280, the last paragraph of Section 5 of an MTU value smaller than 1280, the last paragraph of Section 5 of
RFC2460 [RFC2460] gives it two choices on how to proceed: [RFC2460] gives it two choices on how to proceed:
o It may reduce its Path MTU value to the value indicated in the o It may reduce its Path MTU value to the value indicated in the
Packet Too Big, i.e., limit the size of subsequent packets Packet Too Big, i.e., limit the size of subsequent packets
transmitted to that destination to the indicated value. This transmitted to that destination to the indicated value. This
approach causes no problems for the SIIT-DC function, as it simply approach causes no problems for the SIIT-DC function, as it simply
allows Path MTU Discovery to work transparently across the BR. allows Path MTU Discovery to work transparently across the BR.
o It may reduce its Path MTU value to exactly 1280, and in addition o It may reduce its Path MTU value to exactly 1280, and in addition
include a Fragmentation header in subsequent packets sent to that include a Fragmentation header in subsequent packets sent to that
destination. In other words, the IPv6 node will start emitting destination. In other words, the IPv6 node will start emitting
Atomic Fragments. The Fragmentation header signals to the the BR Atomic Fragments. The Fragmentation header signals to the the BR
that the Don't Fragment flag should be set to 0 in the resulting that the Don't Fragment flag should be set to 0 in the resulting
IPv4 packet, and it also provides the Identification value. IPv4 packet, and it also provides the Identification value.
If the use of the IPv6 Fragmentation header is problematic, and the If the use of the IPv6 Fragmentation header is problematic, and the
operator has IPv6 nodes that implement the second option above, the operator has IPv6 nodes that implement the second option above, the
operator should consider enabling the functionality described as the operator should consider enabling the functionality described as the
"second approach" in Section 6 of RFC6145 [RFC6145]. This "second approach" in Section 6 of [RFC6145]. This functionality
functionality changes the BR's behaviour as follows: changes the BR's behaviour as follows:
o When translating ICMPv4 Need To Fragment to ICMPv6 Packet Too Big, o When translating ICMPv4 Need To Fragment to ICMPv6 Packet Too Big,
the resulting packet will never contain an MTU value lower than the resulting packet will never contain an MTU value lower than
1280. This prevents the IPv6 nodes from generating Atomic 1280. This prevents the IPv6 nodes from generating Atomic
Fragments. Fragments.
o When translating IPv6 packets smaller than or equal to 1280 bytes, o When translating IPv6 packets smaller than or equal to 1280 bytes,
the Don't Fragment flag in the resulting IPv4 packet will be set the Don't Fragment flag in the resulting IPv4 packet will be set
to 0. This ensures that in the eventuality that the path contains to 0. This ensures that in the eventuality that the path contains
an IPv4 link with an MTU smaller than 1260, the IPv4 router an IPv4 link with an MTU smaller than 1260, the IPv4 router
connected to that link will have the responsibility to fragment connected to that link will have the responsibility to fragment
the packet before forwarding it towards its destination. the packet before forwarding it towards its destination.
In summary, this approach could be seen as prompting the IPv4 In summary, this approach could be seen as prompting the IPv4
protocol itself to provide the "link-specific fragmentation and protocol itself to provide the "link-specific fragmentation and
reassembly at a layer below IPv6" required for links that "cannot reassembly at a layer below IPv6" required for links that "cannot
convey a 1280-octet packet in one piece", to paraphrase Section 5 of convey a 1280-octet packet in one piece", to paraphrase Section 5 of
RFC2460 [RFC2460]. [RFC2460].
Note that IPv6 Atomic Fragments are currently being deprecated by Note that IPv6 Atomic Fragments are currently being deprecated by
RFC6145bis [I-D.bao-v6ops-rfc6145bis]. As a result, a BR that RFC6145bis [I-D.bao-v6ops-rfc6145bis]. As a result, a BR that
conforms to the updated standard is required to behave as suggested conforms to the updated standard is required to behave as suggested
above. above.
4.10. IPv4-translatable IPv6 Service Addresses 4.10. IPv4-translatable IPv6 Service Addresses
SIIT-DC is designed so that the IPv6 Service Addresses are not SIIT-DC is designed so that the IPv6 Service Addresses are not
required to be IPv4-translatable IPv6 addresses. Section 2 of I-D required to be IPv4-translatable IPv6 addresses. Section 2 of
.ietf-v6ops-siit-eam [I-D.ietf-v6ops-siit-eam] discusses why it is [I-D.ietf-v6ops-siit-eam] discusses why it is desirable to avoid
desirable to avoid requiring the use of IPv4-translatable IPv6 requiring the use of IPv4-translatable IPv6 addresses.
addresses.
It is however quite possible to deploy SIIT-DC in combination with It is however quite possible to deploy SIIT-DC in combination with
IPv4-translatable IPv6 Service Addresses. The primary benefits in IPv4-translatable IPv6 Service Addresses. The primary benefits in
doing so are: doing so are:
o The operator is not required to provision EAMs for o The operator is not required to provision EAMs for
IPv4-translatable IPv6 Service Addresses onto the BR/ERs. IPv4-translatable IPv6 Service Addresses onto the BR/ERs.
o [RFC6145] translation can be performed in a checksum-neutral o [RFC6145] translation can be performed in a checksum-neutral
manner, cf. Section 4.1 of RFC6052 [RFC6052]. manner, cf. Section 4.1 of [RFC6052].
The trade-off is that the IPv4-translatable IPv6 Service Addresses The trade-off is that the IPv4-translatable IPv6 Service Addresses
must be configured on the IPv6 nodes, and the applications must be must be configured on the IPv6 nodes, and the applications must be
set up to use them - likely in addition to their primary (non- set up to use them - likely in addition to their primary (non-
IPv4-translatable) IPv6 addresses. The IPv4-translatable IPv6 IPv4-translatable) IPv6 addresses. The IPv4-translatable IPv6
Service Addresses must also be routed from the BR through the IDC's Service Addresses must also be routed from the BR through the IDC's
IPv6 network infrastructure to the nodes on which they are assigned. IPv6 network infrastructure to the nodes on which they are assigned.
This essentially requires the entire IPv6 infrastructure to be made This essentially requires the entire IPv6 infrastructure to be made
aware of and handle translated IPv4 traffic as a special case, which aware of and handle translated IPv4 traffic as a special case, which
significantly increases complexity. Avoiding such drawbacks is a significantly increases complexity. As previously described in
design goal of SIIT-DC, cf. Section 1.1, therefore the use of Section 1.1, avoiding such drawbacks is a design goal of SIIT-DC.
IPv4-translatable IPv6 Service Addresses is discouraged. The use of IPv4-translatable IPv6 Service Addresses is therefore
discouraged.
5. Acknowledgements 5. Acknowledgements
The author would like to thank the following individuals for their The author would like to thank the following individuals for their
contributions, suggestions, corrections, and criticisms: Fred Baker, contributions, suggestions, corrections, and criticisms: Fred Baker,
Cameron Byrne, Brian E Carpenter, Ross Chandler, Dagfinn Ilmari Cameron Byrne, Brian E Carpenter, Ross Chandler, Tobias Gondrom,
Mannsaaker, Lars Olafsen, Stig Sandbeck Mathisen, Knut A. Syed, Christer Holmberg, Dagfinn Ilmari Mannsaaker, Lars Olafsen, Stig
Andrew Yourtchenko. Sandbeck Mathisen, Knut A. Syed, Qin Wu, Andrew Yourtchenko.
6. IANA Considerations 6. IANA Considerations
This draft makes no request of the IANA. The RFC Editor may remove This draft makes no request of the IANA.
this section prior to publication.
7. Security Considerations 7. Security Considerations
7.1. Mistaking the Translation Prefix for a Trusted Network 7.1. Mistaking the Translation Prefix for a Trusted Network
If a Network-Specific Prefix from the provider's own address space is If a Network-Specific Prefix from the provider's own address space is
chosen for the translation prefix, as recommended in Section 4.4, chosen for the translation prefix, as recommended in Section 4.4,
care must be taken if the translation service is used in front of care MUST be taken if the translation service is used in front of
services that have application-level ACLs that distinguish between services that have application-level ACLs that distinguish between
the operator's own networks and the Internet at large, as traffic the operator's own networks and the Internet at large, as traffic
from translated IPv4 end users on the Internet might appear to be from translated IPv4 end users on the Internet might appear to be
originating from the provider's own network. It is therefore originating from the provider's own network. It is therefore
important that the translation prefix is treated the same as the important that the translation prefix is treated the same as the
Internet at large, rather than as a trusted network. Internet at large, rather than as a trusted network.
In order to alleviate this problem, the operator may opt to use a In order to alleviate this problem, the operator may opt to use a
Translation Prefix that is distinct from and not a subset of the IPv6 Translation Prefix that is distinct from and not a subset of the IPv6
prefixes used elsewhere in the network infrastructure. prefixes used elsewhere in the network infrastructure.
skipping to change at page 18, line 27 skipping to change at page 18, line 22
<http://www.rfc-editor.org/info/rfc6145>. <http://www.rfc-editor.org/info/rfc6145>.
[RFC6791] Li, X., Bao, C., Wing, D., Vaithianathan, R., and G. [RFC6791] Li, X., Bao, C., Wing, D., Vaithianathan, R., and G.
Huston, "Stateless Source Address Mapping for ICMPv6 Huston, "Stateless Source Address Mapping for ICMPv6
Packets", RFC 6791, DOI 10.17487/RFC6791, November 2012, Packets", RFC 6791, DOI 10.17487/RFC6791, November 2012,
<http://www.rfc-editor.org/info/rfc6791>. <http://www.rfc-editor.org/info/rfc6791>.
8.2. Informative References 8.2. Informative References
[I-D.bao-v6ops-rfc6145bis] [I-D.bao-v6ops-rfc6145bis]
Li, X., Bao, C., Baker, F., Anderson, T., and F. Gont, "IP Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, "IP
/ICMP Translation Algorithm (rfc6145bis)", draft-bao- /ICMP Translation Algorithm (rfc6145bis)", draft-bao-
v6ops-rfc6145bis-01 (work in progress), August 2015. v6ops-rfc6145bis-02 (work in progress), October 2015.
[I-D.ietf-v6ops-siit-dc-2xlat] [I-D.ietf-v6ops-siit-dc-2xlat]
Anderson, T. and S. Steffann, "SIIT-DC: Dual Translation Anderson, T. and S. Steffann, "SIIT-DC: Dual Translation
Mode", draft-ietf-v6ops-siit-dc-2xlat-01 (work in Mode", draft-ietf-v6ops-siit-dc-2xlat-01 (work in
progress), June 2015. progress), June 2015.
[I-D.taylor-v6ops-fragdrop] [I-D.taylor-v6ops-fragdrop]
Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo, Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo,
M., and T. Taylor, "Why Operators Filter Fragments and M., and T. Taylor, "Why Operators Filter Fragments and
What It Implies", draft-taylor-v6ops-fragdrop-02 (work in What It Implies", draft-taylor-v6ops-fragdrop-02 (work in
 End of changes. 40 change blocks. 
122 lines changed or deleted 119 lines changed or added

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