draft-ietf-grow-private-ip-sp-cores-03.txt   draft-ietf-grow-private-ip-sp-cores-04.txt 
Network Working Group A. Kirkham Network Working Group A. Kirkham
Internet-Draft Palo Alto Networks Internet-Draft Palo Alto Networks
Obsoletes: None (if approved) May 7, 2012 Obsoletes: None (if approved) May 12, 2012
Intended status: Informational Intended status: Informational
Expires: November 8, 2012 Expires: November 13, 2012
Issues with Private IP Addressing in the Internet Issues with Private IP Addressing in the Internet
draft-ietf-grow-private-ip-sp-cores-03 draft-ietf-grow-private-ip-sp-cores-04
Abstract Abstract
The purpose of this document is to provide a discussion of the The purpose of this document is to provide a discussion of the
potential problems of using private, RFC1918, or non-globally- potential problems of using private, RFC1918, or non-globally-
routable addressing within the core of an SP network. The discussion routable addressing within the core of an SP network. The discussion
focuses on link addresses and to a small extent loopback addresses. focuses on link addresses and to a small extent loopback addresses.
While many of the issues are well recognised within the ISP While many of the issues are well recognised within the ISP
community, there appears to be no document that collectively community, there appears to be no document that collectively
describes the issues. describes the issues.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 November 8, 2012. This Internet-Draft will expire on November 13, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 27 skipping to change at page 2, line 27
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conservation of Address Space . . . . . . . . . . . . . . . . 3 2. Conservation of Address Space . . . . . . . . . . . . . . . . 3
3. Effects on Traceroute . . . . . . . . . . . . . . . . . . . . 4 3. Effects on Traceroute . . . . . . . . . . . . . . . . . . . . 4
4. Effects on Path MTU Discovery . . . . . . . . . . . . . . . . 7 4. Effects on Path MTU Discovery . . . . . . . . . . . . . . . . 7
5. Unexpected interactions with some NAT implementations . . . . 8 5. Unexpected interactions with some NAT implementations . . . . 8
6. Interactions with edge anti-spoofing techniques . . . . . . . 10 6. Interactions with edge anti-spoofing techniques . . . . . . . 9
7. Peering using loopbacks . . . . . . . . . . . . . . . . . . . 10 7. Peering using loopbacks . . . . . . . . . . . . . . . . . . . 10
8. DNS Interaction . . . . . . . . . . . . . . . . . . . . . . . 11 8. DNS Interaction . . . . . . . . . . . . . . . . . . . . . . . 10
9. Operational and Troubleshooting issues . . . . . . . . . . . . 11 9. Operational and Troubleshooting issues . . . . . . . . . . . . 10
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11
11. Alternate approaches to core network security . . . . . . . . 13 11. Alternate approaches to core network security . . . . . . . . 12
12. Normative References . . . . . . . . . . . . . . . . . . . . . 14 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.1. Normative References . . . . . . . . . . . . . . . . . . 13
12.2. informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 14 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
In the mid to late 90's, some Internet Service Providers (ISPs) In the mid to late 90's, some Internet Service Providers (ISPs)
adopted the practice of utilising private (or non-globally unique) IP adopted the practice of utilising private (or non-globally unique)
(i.e. RFC1918) addresses for the infrastructure links and in some [RFC1918] IP addresses for the infrastructure links and in some cases
cases the loopback interfaces within their networks. The reasons for the loopback interfaces within their networks. The reasons for this
this approach centered on conservation of address space (i.e. approach centered on conservation of address space (i.e. scarcity of
scarcity of public IPv4 address space), and security of the core public IPv4 address space), and security of the core network (also
network (also known as core hiding). known as core hiding).
However, a number of technical and operational issues occurred as a However, a number of technical and operational issues occurred as a
result of using private (or non-globally unique) IP addresses, and result of using private (or non-globally unique) IP addresses, and
virtually all these ISPs moved away from the practice. Tier 1 ISPs virtually all these ISPs moved away from the practice. Tier 1 ISPs
are considered the benchmark of the industry and as of the time of are considered the benchmark of the industry and as of the time of
writing, there is no known tier 1 ISP that utilises the practice of writing, there is no known tier 1 ISP that utilises the practice of
private addressing within their core network. private addressing within their core network.
The following sections will discuss the various issues associated The following sections will discuss the various issues associated
with deploying private IP (i.e. RFC1918) addresses within ISP core with deploying private [RFC1918] IP addresses within ISP core
networks. networks.
The intent of this document is not to suggest that private IP can not The intent of this document is not to suggest that private IP can not
be used with the core of an SP network as some providers use this be used with the core of an SP network as some providers use this
practice and operate successfully. The intent is to outline the practice and operate successfully. The intent is to outline the
potential issues or effects of such a practice. potential issues or effects of such a practice.
Note: The practice of ISPs using 'stolen' address space (also known Note: The practice of ISPs using 'stolen' address space (also known
as 'squat' space) has many of the same issues (or effects) as that of as 'squat' space) has many of the same issues (or effects) as that of
using private IP address space within core networks. The term using private IP address space within core networks. The term
skipping to change at page 4, line 22 skipping to change at page 4, line 22
(2) IP addresses per point to point link versus four (4) (2) IP addresses per point to point link versus four (4)
respectively. respectively.
The use of private addressing as a conservation technique within an The use of private addressing as a conservation technique within an
Internet Service Provider (ISP) core can cause a number of technical Internet Service Provider (ISP) core can cause a number of technical
and operational issues or effects. The main effects are described and operational issues or effects. The main effects are described
below. below.
3. Effects on Traceroute 3. Effects on Traceroute
The single biggest effect caused by the use of private (RFC1918) The single biggest effect caused by the use of private [RFC1918]
addressing within an Internet core is the fact that it can disrupt addressing within an Internet core is the fact that it can disrupt
the operation of traceroute in some situations. This section the operation of traceroute in some situations. This section
provides some examples of the issues that can occur. provides some examples of the issues that can occur.
A first example illustrates the situation where the traceroute A first example illustrates the situation where the traceroute
crosses an AS boundary and one of the networks has utilised private crosses an AS boundary and one of the networks has utilised private
addressing. The following simple network is used to show the addressing. The following simple network is used to show the
effects. effects.
AS64496 EBGP AS64497 AS64496 EBGP AS64497
skipping to change at page 5, line 24 skipping to change at page 5, line 24
3 198.51.100.9 20 msec 20 msec 32 msec 3 198.51.100.9 20 msec 20 msec 32 msec
4 10.1.1.5 20 msec 20 msec 20 msec 4 10.1.1.5 20 msec 20 msec 20 msec
5 10.1.1.1 20 msec 20 msec 20 msec 5 10.1.1.1 20 msec 20 msec 20 msec
R6# R6#
This effect in itself is often not a problem. However, if anti- This effect in itself is often not a problem. However, if anti-
spoofing controls are applied at network perimeters, then responses spoofing controls are applied at network perimeters, then responses
returned from hops with private IP addresses will be dropped. Anti- returned from hops with private IP addresses will be dropped. Anti-
spoofing refers to a security control where traffic with an invalid spoofing refers to a security control where traffic with an invalid
source address is discarded. Anti-spoofing is further described in source address is discarded. Anti-spoofing is further described in
[BCP 38]/[RFC 2827]. [BCP38]/[RFC2827].
The effects are illustrated in a second example below. The same The effects are illustrated in a second example below. The same
network as example 1 is used, but with the addition of anti-spoofing network as example 1 is used, but with the addition of anti-spoofing
deployed at the ingress of R4 on the R3-R4 interface (IP Address deployed at the ingress of R4 on the R3-R4 interface (IP Address
198.51.100.10). 198.51.100.10).
R6#traceroute 203.0.113.1 R6#traceroute 203.0.113.1
Type escape sequence to abort. Type escape sequence to abort.
Tracing the route to 203.0.113.1 Tracing the route to 203.0.113.1
skipping to change at page 7, line 27 skipping to change at page 7, line 27
Tracing the route to 203.0.113.65 Tracing the route to 203.0.113.65
1 10.1.1.2 0 msec 4 msec 0 msec 1 10.1.1.2 0 msec 4 msec 0 msec
2 10.1.1.6 0 msec 4 msec 0 msec 2 10.1.1.6 0 msec 4 msec 0 msec
3 198.51.100.10 [AS 64497] 0 msec 4 msec 0 msec 3 198.51.100.10 [AS 64497] 0 msec 4 msec 0 msec
4 198.51.100.5 [AS 64497] 0 msec 0 msec 4 msec 4 198.51.100.5 [AS 64497] 0 msec 0 msec 4 msec
5 198.51.100.1 [AS 64497] 0 msec 0 msec 4 msec 5 198.51.100.1 [AS 64497] 0 msec 0 msec 4 msec
R1# R1#
It should be noted that some solutions to this problem have been It should be noted that some solutions to this problem have been
proposed in [RFC 5837] which provides extensions to ICMP to allow the proposed in [RFC5837] which provides extensions to ICMP to allow the
identification of interfaces and their components by any combination identification of interfaces and their components by any combination
of the following: ifIndex, IPv4 address, IPv6 address, name, and of the following: ifIndex, IPv4 address, IPv6 address, name, and
MTU. However at the time of writing, little or no deployment was MTU. However at the time of writing, little or no deployment was
known to be in place. known to be in place.
4. Effects on Path MTU Discovery 4. Effects on Path MTU Discovery
The Path MTU Discovery (PMTUD) process was designed to allow hosts to The Path MTU Discovery (PMTUD) process was designed to allow hosts to
make an accurate assessment of the maximum packet size that can be make an accurate assessment of the maximum packet size that can be
sent across a path without fragmentation. Path MTU Discovery is sent across a path without fragmentation. Path MTU Discovery is
supported for TCP (and other protocols that support PMTUD such as GRE supported by TCP over IPv4 [RFC1191], TCP over IPv6 [RFC1981] and
and IPsec) and works as follows: some tunneling protocols such as GRE and IPSEC.
o When a router attempts to forward an IP datagram with the Do Not
Fragment (DF) bit set out a link that has a lower MTU than the size
of the packet, the router MUST drop the packet and return an Internet
Control Message Protocol (ICMP) 'destination unreachable -
fragmentation needed and DF set (type 3, code 4)' message to the
source of the IP datagram. This message includes the MTU of that
next-hop network. As a result, the source station which receives the
ICMP message, will lower the send Maximum Segment Size (MSS).
It is obviously desirable that packets be sent between two
communicating hosts without fragmentation as this process imposes
extra load on the fragmenting router (process of fragmentation),
intermediate routers (forwarding additional packets), as well as the
receiving host (reassembly of the fragmented packets). Additionally,
many applications, including some web servers, set the DF (Do Not
Fragment) bit causing undesirable interactions if the path MTU is
insufficient. Other TCP implementations may set an MTU size of 576
bytes if PMTUD is unavailable. In addition, IPsec and other
tunneling protocols will often require MTUs greater than 1500 bytes
and often rely on PMTUD.
While it is uncommon these days for core SP networks not to support
path MTUs in excess of 1500 bytes (with 4470 or greater being
common), the situation of 1500 byte path MTUs is still common in many
ethernet edge or aggregation networks.
The issue is as follows:
o When an ICMP Type 3 Code 4 message is issued from an infrastructure
link that uses a private (RFC1918) address, it must be routed back to
the originating host. As the originating host will typically be a
globally routable IP address, its source address is used as the
destination address of the returned ICMP Type 3 packet. At this
point there are normally no problems.
o As the returned packet will have an [RFC1918] source address,
problems can occur when the returned packet passes through an anti-
spoofing security control (such as Unicast RPF (uRPF)), other anti-
spoofing ACLs, or virtually any perimeter firewall. These devices
will typically drop packets with an [RFC1918] source address,
breaking the successful operation of PMTUD.
As a result, the potential for application level issues may be The PMTUD mechanism requires that an intermediate router can reply to
created. the source address of an IP packet with an ICMP reply which uses the
router's interface address. If the router's interface address is a
private IP address, then this ICMP reply packet may be discarded due
to uRPF or ingress filtering, thereby causing the PMTUD mechanism to
fail. If the PMTUD mechanism fails, this will cause transmission of
data between the two hosts to fail silently due to the traffic being
black-holed. As a result, the potential for application level issues
may be created.
5. Unexpected interactions with some NAT implementations 5. Unexpected interactions with some NAT implementations
Private addressing is legitimately used within many enterprise, Private addressing is legitimately used within many enterprise,
corporate or government networks for internal network addressing. corporate or government networks for internal network addressing.
When users on the inside of the network require Internet access, they When users on the inside of the network require Internet access, they
will typically connect through a perimeter router, firewall, or will typically connect through a perimeter router, firewall, or
network proxy, that provides Network Address Translation (NAT) or network proxy, that provides Network Address Translation (NAT) or
Network Address Port Translation (NAPT) services to a public Network Address Port Translation (NAPT) services to a public
interface. interface.
Scarcity of public IPv4 addresses, and the transition to IPv6, is Scarcity of public IPv4 addresses, and the transition to IPv6, is
forcing many service providers to make use of NAT. CGN (Carrier forcing many service providers to make use of NAT. CGN (Carrier
Grade NAT) will enable service providers to assign private [RFC 1918] Grade NAT) will enable service providers to assign private [RFC1918]
IPv4 addresses to their customers rather than public, globally unique IPv4 addresses to their customers rather than public, globally unique
IPv4 addresses. NAT444 will make use of a double NAT process. IPv4 addresses. NAT444 will make use of a double NAT process.
Unpredictable or confusing interactions could occur if traffic such Unpredictable or confusing interactions could occur if traffic such
as traceroute, PMTUD and possibly other applications were launched as traceroute, PMTUD and possibly other applications were launched
from the NAT IPv4 'inside address' and it passed over the same from the NAT IPv4 'inside address' and it passed over the same
address range in the public IP core. While such a situation would be address range in the public IP core. While such a situation would be
unlikely to occur if the NAT pools and the private infrastructure unlikely to occur if the NAT pools and the private infrastructure
addressing were under the same administration, such a situation could addressing were under the same administration, such a situation could
occur in the more typical situation of a NAT'ed corporate network occur in the more typical situation of a NAT'ed corporate network
skipping to change at page 9, line 47 skipping to change at page 9, line 17
Type escape sequence to abort. Type escape sequence to abort.
Tracing the route to 198.51.100.100 Tracing the route to 198.51.100.100
1 10.1.1.2 0 msec 0 msec 0 msec 1 10.1.1.2 0 msec 0 msec 0 msec
2 198.51.100.13 0 msec 4 msec 0 msec 2 198.51.100.13 0 msec 4 msec 0 msec
3 10.1.1.2 0 msec 4 msec 0 msec <<<< 3 10.1.1.2 0 msec 4 msec 0 msec <<<<
4 198.51.100.5 4 msec 0 msec 4 msec 4 198.51.100.5 4 msec 0 msec 4 msec
5 198.51.100.1 0 msec 0 msec 0 msec 5 198.51.100.1 0 msec 0 msec 0 msec
R1# R1#
This example has been included to illustrate an effect. Whether that This overlapping address space configuration is likely to cause
effect would be problematic would depend on both the deployment confusion among operational staff, thereby making it more difficult
scenario and the application in use. to successfully debug networking problems.
Certainly a scenario where the same [RFC1918] address space becomes Certainly a scenario where the same [RFC1918] address space becomes
utilised on both the inside and outside interfaces of a NAT/NAPT utilised on both the inside and outside interfaces of a NAT/NAPT
device can be problematic. For example, the same private address device can be problematic. For example, the same private address
range is assigned by both the administrator of a corporate network range is assigned by both the administrator of a corporate network
and their ISP. Some applications discover the outside address of and their ISP. Some applications discover the outside address of
their local CPE to determine if that address is reserver for special their local CPE to determine if that address is reserver for special
use. Application behavior may then be based on this determination. use. Application behavior may then be based on this determination.
[RFC6598] provides further analysis of this situation. "IANA-Reserved IPv4 Prefix for Shared Address Space" [RFC6598]
provides further analysis of this situation.
To address this scenario and others, [RFC6598] requests a dedicated To address this scenario and others, "IANA-Reserved IPv4 Prefix for
/10 address block for the purpose of Shared CGN (Carrier Grade NAT) Shared Address Space" [RFC6598] requests a dedicated /10 address
Address Space. The purpose of Shared CGN Address Space is to number block for the purpose of Shared CGN (Carrier Grade NAT) Address
CPE (Customer Premise Equipment) interfaces that connect to CGN Space. The purpose of Shared CGN Address Space is to number CPE
devices. As explained in [RFC6598], [RFC1918] addressing has issues (Customer Premise Equipment) interfaces that connect to CGN devices.
when used in this deployment scenario. As explained in [RFC6598], [RFC1918] addressing has issues when used
in this deployment scenario.
6. Interactions with edge anti-spoofing techniques 6. Interactions with edge anti-spoofing techniques
Denial of Service Attacks (DOS) and Distributed Denial of Service Denial of Service Attacks (DOS) and Distributed Denial of Service
Attacks (DDoS) can make use of spoofed source IP addresses in an Attacks (DDoS) can make use of spoofed source IP addresses in an
attempt to obfuscate the source of an attack. [RFC2827] (Network attempt to obfuscate the source of an attack. Network Ingress
Ingress Filtering) strongly recommends that providers of Internet Filtering [RFC2827] strongly recommends that providers of Internet
connectivity implement filtering to prevent packets using source connectivity implement filtering to prevent packets using source
addresses outside of their legitimately assigned and advertised addresses outside of their legitimately assigned and advertised
prefix ranges. Such filtering should also prevent packets with prefix ranges. Such filtering should also prevent packets with
private source addresses from egressing the AS. private source addresses from egressing the AS.
Best security practices for ISPs also strongly recommend that packets Best security practices for ISPs also strongly recommend that packets
with illegitimate source addresses should be dropped at the AS with illegitimate source addresses should be dropped at the AS
perimeter. Illegitimate source addresses includes private IP perimeter. Illegitimate source addresses includes private
(RFC1918) addresses, addresses within the provider's assigned prefix [RFC1918]IP addresses, addresses within the provider's assigned
ranges, and bogons (legitimate but unassigned IP addresses). prefix ranges, and bogons (legitimate but unassigned IP addresses).
Additionally, packets with private IP destination addresses should Additionally, packets with private IP destination addresses should
also be dropped at the AS perimeter. also be dropped at the AS perimeter.
If such filtering is properly deployed, then traffic either sourced If such filtering is properly deployed, then traffic either sourced
from, or destined for privately addressed portions of the network from, or destined for privately addressed portions of the network
should be dropped. Hence the negative consequences on traceroute, should be dropped. Hence the negative consequences on traceroute,
PMTUD and regular ping type traffic. PMTUD and regular ping type traffic.
7. Peering using loopbacks 7. Peering using loopbacks
skipping to change at page 11, line 24 skipping to change at page 10, line 39
resolution for the infrastructure devices and infrastructure resolution for the infrastructure devices and infrastructure
addresses. With a privately numbered core, the ISP itself will still addresses. With a privately numbered core, the ISP itself will still
have the capability to perform name resolution of their own have the capability to perform name resolution of their own
infrastructure. However others outside of the autonomous system will infrastructure. However others outside of the autonomous system will
not have this capability. At best, they will get a number of not have this capability. At best, they will get a number of
unidentified [RFC1918] IP addresses returned from a traceroute. unidentified [RFC1918] IP addresses returned from a traceroute.
It is also worth noting that in some cases the reverse resolution It is also worth noting that in some cases the reverse resolution
requests may leak outside of the AS. Such a situation can add load requests may leak outside of the AS. Such a situation can add load
to public DNS servers. Further information on this problem is to public DNS servers. Further information on this problem is
documented in the internet draft "AS112 Nameserver Operations". documented in "AS112 Nameserver Operations" [RFC6304].
9. Operational and Troubleshooting issues 9. Operational and Troubleshooting issues
Previous sections of the document have noted issues relating to Previous sections of the document have noted issues relating to
network operations and troubleshooting. In particular when private network operations and troubleshooting. In particular when private
IP addressing within an ISP core is used, the ability to easily IP addressing within an ISP core is used, the ability to easily
troubleshoot across the AS boundary may be limited. In some cases troubleshoot across the AS boundary may be limited. In some cases
this may be a serious troubleshooting impediment. In other cases, it this may be a serious troubleshooting impediment. In other cases, it
may be solved through the use of alternative troubleshooting may be solved through the use of alternative troubleshooting
techniques. techniques.
skipping to change at page 14, line 5 skipping to change at page 13, line 23
traceroute. While this approach isolates the 'P' routers from traceroute. While this approach isolates the 'P' routers from
directed attacks, it does not protect the edge routers - being either directed attacks, it does not protect the edge routers - being either
a 'PE' router or a Label Edge Router (LER). Obviously there are a 'PE' router or a Label Edge Router (LER). Obviously there are
numerous other engineering considerations in such an approach, we numerous other engineering considerations in such an approach, we
simply note it as an option. simply note it as an option.
These techniques may not be suitable for every network, however, These techniques may not be suitable for every network, however,
there are many circumstances where they can be used successfully there are many circumstances where they can be used successfully
without the associated effects of a privately addressing the core. without the associated effects of a privately addressing the core.
12. Normative References 12. References
12.1. Normative References
[BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", May 2000.
[BCP84] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", March 2004.
[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", [RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery",
November 1990. November 1990.
[RFC1393] Malkin, G., "Traceroute Using an IP Option", January 1993. [RFC1393] Malkin, G., "Traceroute Using an IP Option", January 1993.
[RFC1918] Rekhter , Y., Moskowitz, R., Karrenberg, D., Jan de Groot, [RFC1918] Rekhter , Y., Moskowitz, R., Karrenberg, D., Jan de Groot,
G., and E. Lear , "RFC1918 Address Allocation for Private G., and E. Lear , "RFC1918 Address Allocation for Private
Internets, BCP 5", Febuary 1996. Internets, BCP 5", Febuary 1996.
[RFC2728] Ferguson, P. and D. Senie , "RFC 2827 Network Ingress [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", August 1996.
[RFC2827] Ferguson, P. and D. Senie , "RFC 2827 Network Ingress
Filtering, BCP 38", May 2000. Filtering, BCP 38", May 2000.
12.2. informative References
[RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson, [RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson,
"Using 31-Bit Prefixes on IPv4 Point-to-Point Links", "Using 31-Bit Prefixes on IPv4 Point-to-Point Links",
December 2000. December 2000.
[RFC5837] Atlas, A., Bonica, Pignataro, C., Shen, N., and Rivers,
JR., "Extending ICMP for Interface and Next-Hop
Identification", April 2010.
[RFC6304] Abley, J. and W. Maton, "AS112 Nameserver Operations", [RFC6304] Abley, J. and W. Maton, "AS112 Nameserver Operations",
July 2011. July 2011.
[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and
M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address
Space", April 2012. Space", April 2012.
[RFC792] Postel, J., "RFC792 Internet Control Message Protocol", [RFC792] Postel, J., "RFC792 Internet Control Message Protocol",
September 1981. September 1981.
Appendix A. Acknowledgments Appendix A. Acknowledgments
The author would like to thank the following people for their input The author would like to thank the following people for their input
and review - Dan Wing (Cisco Systems), Roland Dobbins (Arbor and review - Dan Wing (Cisco Systems), Roland Dobbins (Arbor
Networks), Philip Smith (APNIC), Barry Greene (ISC), Anton Ivanov Networks), Philip Smith (APNIC), Barry Greene (ISC), Anton Ivanov
(kot-begemot.co.uk), Ryan Mcdowell (Cisco Systems), Russ White (Cisco (kot-begemot.co.uk), Ryan Mcdowell (Cisco Systems), Russ White (Cisco
Systems), Gregg Schudel (Cisco Systems), Michael Behringer (Cisco Systems), Gregg Schudel (Cisco Systems), Michael Behringer (Cisco
Systems), Stephan Millet (Cisco Systems), Tom Petch (BT Connect), Wes Systems), Stephan Millet (Cisco Systems), Tom Petch (BT Connect), Wes
George (Time Warner Cable). George (Time Warner Cable), Nick Hilliard (INEX).
The author would also like to acknowledge the use of a variety of The author would also like to acknowledge the use of a variety of
NANOG mail archives as references. NANOG mail archives as references.
Author's Address Author's Address
Anthony Kirkham Anthony Kirkham
Palo Alto Networks Palo Alto Networks
Level 32, 101 Miller St Level 32, 101 Miller St
North Sydney, New South Wales 2060 North Sydney, New South Wales 2060
 End of changes. 25 change blocks. 
86 lines changed or deleted 73 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/