One document matched: draft-ietf-grow-private-ip-sp-cores-07.xml
<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629-fixed.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY ADDARCH SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3513.xml">
<!ENTITY GLOBAL SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3587.xml">
<!ENTITY ICMPv6 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4443.xml">
<!ENTITY IPv6 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml">
<!ENTITY NTP SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1305.xml">
<!ENTITY RANDOM SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4086.xml">
<!ENTITY SHA1 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3174.xml">
<!ENTITY ULA SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4193.xml">
<!ENTITY FIPS SYSTEM "http://xml.resource.org/public/rfc/bibxml2/reference.FIPS.180-1.1995.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="no"?>
<?rfc inline="yes"?>
<?rfc subcompact="no"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes"?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc colonspace='yes' ?>
<rfc category="info" docName="draft-ietf-grow-private-ip-sp-cores-07"
ipr="trust200902" obsoletes="None" submissionType="IETF" updates=""
xml:lang="en">
<front>
<title abbrev="private-ip-sp-cores">Issues with Private IP Addressing in
the Internet</title>
<author fullname="Anthony Kirkham" initials="A." surname="Kirkham">
<organization>Palo Alto Networks</organization>
<address>
<postal>
<street>Level 32, 101 Miller St</street>
<street></street>
<city>North Sydney</city>
<region>New South Wales</region>
<code>2060</code>
<country>Australia</country>
</postal>
<phone>+61 7 33530902</phone>
<email>tkirkham@paloaltonetworks.com</email>
</address>
</author>
<date day="30" month="July" year="2012" />
<abstract>
<t>The purpose of this document is to provide a discussion of the
potential problems of using private, RFC1918, or non-globally-routable
addressing within the core of an SP network. The discussion focuses on
link addresses and to a small extent loopback addresses. While many of
the issues are well recognised within the ISP community, there appears
to be no document that collectively describes the issues.</t>
</abstract>
<note title="Legal">
<t>This documents and the information contained therein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.</t>
</note>
</front>
<middle>
<section title="Introduction" toc="default">
<t>In the mid to late 90's, some Internet Service Providers (ISPs)
adopted the practice of utilising private (or non-globally unique) <xref
target="RFC1918"></xref> IP addresses for the infrastructure links and
in some cases the loopback interfaces within their networks. The reasons
for this approach centered on conservation of address space (i.e.
scarcity of public IPv4 address space), and security of the core network
(also known as core hiding).</t>
<t>However, a number of technical and operational issues occurred as a
result of using private (or non-globally unique) IP addresses, and
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 writing,
there is no known tier 1 ISP that utilises the practice of private
addressing within their core network.</t>
<t>The following sections will discuss the various issues associated
with deploying private <xref target="RFC1918"></xref> IP addresses
within ISP core networks.</t>
<t>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
practice and operate successfully. The intent is to outline the
potential issues or effects of such a practice.</t>
<t>Note: The practice of ISPs using ‘squat’ address space (also known as
'stolen' space) has many of the same, plus some additional issues (or
effects) as that of using private IP address space within core networks.
The term “squat IP address space” refers to the practice of an ISP using
address space for its own infrastructure/core network addressing that
has been officially allocated by an RIR (Regional Internet Registry) to
another provider, but that provider is not currently using or
advertising within the Internet. Squat addressing is not discussed
further in this document. It is simply noted as an associated issue.</t>
</section>
<section title="Conservation of Address Space">
<t>One of the original intents for the use of private IP addressing
within an ISP core was the conservation of IP address space. When an ISP
is allocated a block of public IP addresses (from a RIR), this address
block was traditionally split in order to dedicate some portion for
infrastructure use (i.e. for the core network), and the other portion
for customer (subscriber) or other address pool use. Typically, the
number of infrastructure addresses needed is relatively small in
comparison to the total address count. So unless the ISP was only
granted a small public block, dedicating some portion to infrastructure
links and loopback addresses (/32) is rarely a large enough issue to
outweigh the problems that are potentially caused when private address
space is used.</t>
<t>Additionally, specifications and equipment capability improvements
now allow for the use of /31 subnets <xref target="RFC3021"></xref> for
link addresses in place of the original /30 subnets – further minimising
the impact of dedicating public addresses to infrastructure links by
only using two (2) IP addresses per point to point link versus four (4)
respectively.</t>
<t>The use of private addressing as a conservation technique within an
Internet Service Provider (ISP) core can cause a number of technical and
operational issues or effects. The main effects are described below.</t>
</section>
<section title="Effects on Traceroute">
<t>The single biggest effect caused by the use of private <xref
target="RFC1918"></xref> addressing within an Internet core is the fact
that it can disrupt the operation of traceroute in some situations. This
section provides some examples of the issues that can occur.</t>
<t>A first example illustrates the situation where the traceroute
crosses an AS boundary and one of the networks has utilised private
addressing. The following simple network is used to show the
effects.</t>
<figure>
<artwork>
AS64496 EBGP AS64497
IBGP Mesh <---------------> IBGP Mesh
R1 Pool - R6 Pool -
203.0.113.0/26 203.0.113.64/26
198.51.100.8/30
198.51.100.4/30
10.1.1.0/30 10.1.1.4/30 198.51.100.0/30
.9 .10
.1 .2 .5 .6 ------------ .6 .5 .2 .1
R1-----------R2-----------R3--| |--R4----------R5----------R6
R1 Loopback: 10.1.1.101 R4 Loopback: 198.51.100.103
R2 Loopback: 10.1.1.102 R5 Loopback: 198.51.100.102
R3 Loopback: 10.1.1.103 R6 Loopback: 198.51.100.101
</artwork>
</figure>
<t>Using this example, performing the traceroute from AS64497 to
AS64496, we can see the private addresses of the infrastructure links in
AS64496 are returned.</t>
<figure>
<artwork>
R6#traceroute 203.0.113.1
Type escape sequence to abort.
Tracing the route to 203.0.113.1
1 198.51.100.2 40 msec 20 msec 32 msec
2 198.51.100.6 16 msec 20 msec 20 msec
3 198.51.100.9 20 msec 20 msec 32 msec
4 10.1.1.5 20 msec 20 msec 20 msec
5 10.1.1.1 20 msec 20 msec 20 msec
R6#
</artwork>
</figure>
<t>This effect in itself is often not a problem. However, if
anti-spoofing controls are applied at network perimeters, then responses
returned from hops with private IP addresses will be dropped.
Anti-spoofing refers to a security control where traffic with an invalid
source address is discarded. Anti-spoofing is further described in <xref
target="BCP38"></xref>/<xref target="RFC2827"></xref>and<xref
target="BCP84"></xref>/<xref target="RFC3704"></xref>. Additionally any
RFC1918 filtering mechanism, such as those employed in most firewalls
and many other network devices can cause the same effect.</t>
<t>The effects are illustrated in a second example below. The same
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
198.51.100.10).</t>
<figure>
<artwork>
R6#traceroute 203.0.113.1
Type escape sequence to abort.
Tracing the route to 203.0.113.1
1 198.51.100.2 24 msec 20 msec 20 msec
2 198.51.100.6 20 msec 52 msec 44 msec
3 198.51.100.9 44 msec 20 msec 32 msec
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
</artwork>
</figure>
<t>In a third example, a similar effect is caused. If a traceroute is
initiated from a router with a private (source) IP address, located in
AS64496 and the destination is outside of the ISPs AS (AS64497), then in
this situation the traceroute will fail completely beyond the AS
boundary.</t>
<figure>
<artwork>
R1# traceroute 203.0.113.65
Type escape sequence to abort.
Tracing the route to 203.0.113.65
1 10.1.1.2 20 msec 20 msec 20 msec
2 10.1.1.6 52 msec 24 msec 40 msec
3 * * *
4 * * *
5 * * *
6 * * *
R1#
</artwork>
</figure>
<t>While it is completely unreasonable to expect a packet with a private
source address to be successfully returned in a typical SP environment,
the case is included to show the effect as it can have implications for
troubleshooting. This case will be referenced in a later section.</t>
<t>In a complex topology, with multiple paths and exit points, the
provider will lose their ability to trace paths originating within their
own AS, through their network, to destinations within other ASs. Such a
situation could be a severe troubleshooting impediment.</t>
<t>For completeness, a fourth example is included to show that a
successful traceroute can be achieved by specifying a public source
address as the source address of the traceroute. Such an approach can be
used in many operational situations if the router initiating the
traceroute has at least one public address configured. However, the
approach is more cumbersome.</t>
<figure>
<artwork>
R1#traceroute
Protocol [ip]:
Target IP address: 203.0.113.65
Source address: 203.0.113.1
Numeric display [n]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]: 10
Port Number [33434]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Type escape sequence to abort.
Tracing the route to 203.0.113.65
1 10.1.1.2 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
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
R1#
</artwork>
</figure>
<t>It should be noted that some solutions to this problem have been
proposed in <xref target="RFC5837"></xref> which provides extensions to
ICMP to allow the identification of interfaces and their components by
any combination of the following: ifIndex, IPv4 address, IPv6 address,
name, and MTU. However at the time of writing, little or no deployment
was known to be in place.</t>
</section>
<section title="Effects on Path MTU Discovery">
<t>The Path MTU Discovery (PMTUD) process was designed to allow hosts to
make an accurate assessment of the maximum packet size that can be sent
across a path without fragmentation. Path MTU Discovery is utilized by
IPv4 <xref target="RFC1191"></xref>, IPv6 <xref target="RFC1981"></xref>
and some tunnelling protocols such as GRE and IPSEC.</t>
<t>The PMTUD mechanism requires that an intermediate router can reply to
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.</t>
</section>
<section title="Unexpected interactions with some NAT implementations">
<t>Private addressing is legitimately used within many enterprise,
corporate or government networks for internal network addressing. When
users on the inside of the network require Internet access, they will
typically connect through a perimeter router, firewall, or network
proxy, that provides Network Address Translation (NAT) or Network
Address Port Translation (NAPT) services to a public interface.</t>
<t>Scarcity of public IPv4 addresses is forcing many service providers
to make use of NAT. CGN (Carrier Grade NAT) will enable service
providers to assign private <xref target="RFC1918"></xref> IPv4
addresses to their customers rather than public, globally unique IPv4
addresses. NAT444 will make use of a double NAT process.</t>
<t>Unpredictable or confusing interactions could occur if traffic such
as traceroute, PMTUD and possibly other applications were launched 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 unlikely to occur
if the NAT pools and the private infrastructure addressing were under
the same administration, such a situation could occur in the more
typical situation of a NAT'ed corporate network connecting to an ISP.
For example, say if 10.1.1.0/24 is used to internally number the
corporate network. A traceroute or PMTUD request is initiated inside the
corporate network from say 10.1.1.1. The packet passes through a NAT (or
NAPT) gateway, then over an ISP core numbered from the same range. When
the responses are delivered back to the originator, the returned packets
from the privately addressed part of the ISP core could have an
identical source and destination address of 10.1.1.1.</t>
<figure>
<artwork>
NAT Pool -
203.0.113.0/24
10.1.1.0/30 10.1.1.0/30 198.51.100.0/30
198.51.100.12/30 198.51.100.4/30
.1 .2 .14 .13 .1 .2 .6 .5 .2 .1
R1-----------R2-----------R3---------------R4----------R5----------R6
NAT
R6 Loopback:
198.51.100.100
</artwork>
</figure>
<figure>
<artwork>
R1#traceroute 198.51.100.100
Type escape sequence to abort.
Tracing the route to 198.51.100.100
1 10.1.1.2 0 msec 0 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 <<<<
4 198.51.100.5 4 msec 0 msec 4 msec
5 198.51.100.1 0 msec 0 msec 0 msec
R1#
</artwork>
</figure>
<t>This duplicate address space scenario has the potential to cause
confusion among operational staff, thereby making it more difficult to
successfully debug networking problems.</t>
<t>Certainly a scenario where the same <xref target="RFC1918"></xref>
address space becomes utilised on both the inside and outside interfaces
of a NAT/NAPT device can be problematic. For example, the same private
address range is assigned by both the administrator of a corporate
network and their ISP. Some applications discover the outside address of
their local CPE to determine if that address is reserved for special
use. Application behaviour may then be based on this determination.
<xref target="RFC6598">"IANA-Reserved IPv4 Prefix for Shared Address
Space"</xref> provides further analysis of this situation.</t>
<t>To address this scenario and others, <xref
target="RFC6598">"IANA-Reserved IPv4 Prefix for Shared Address
Space"</xref> allocated a dedicated /10 address block for the purpose of
Shared CGN (Carrier Grade NAT) Address Space: 100.64.0.0/10. The purpose
of Shared CGN Address Space is to number CPE (Customer Premise
Equipment) interfaces that connect to CGN devices. As explained in <xref
target="RFC6598"></xref>, <xref target="RFC1918"></xref> addressing has
issues when used in this deployment scenario.</t>
</section>
<section title="Interactions with edge anti-spoofing techniques">
<t>Denial of Service Attacks (DOS) and Distributed Denial of Service
Attacks (DDoS) can make use of spoofed source IP addresses in an attempt
to obfuscate the source of an attack. <xref target="RFC2827">Network
Ingress Filtering</xref> strongly recommends that providers of Internet
connectivity implement filtering to prevent packets using source
addresses outside of their legitimately assigned and advertised prefix
ranges. Such filtering should also prevent packets with private source
addresses from egressing the AS.</t>
<t>Best security practices for ISPs also strongly recommend that packets
with illegitimate source addresses should be dropped at the AS
perimeter. Illegitimate source addresses includes private <xref
target="RFC1918"></xref> IP addresses, addresses within the provider's
assigned prefix ranges, and bogons (legitimate but unassigned IP
addresses). Additionally, packets with private IP destination addresses
should also be dropped at the AS perimeter.</t>
<t>If such filtering is properly deployed, then traffic either sourced
from, or destined for privately addressed portions of the network should
be dropped. Hence the negative consequences on traceroute, PMTUD and
regular ping type traffic.</t>
</section>
<section title="Peering using loopbacks">
<t>Some ISPs use the loopback addresses of border routers (ASBRs) for
peering, in particular where multiple connections or exchange points
exist between the two ISPs. Such a technique is used by some ISPs as the
foundation of fine grained traffic engineering and load balancing
through the combination of IGP metrics and multi-hop BGP. When private
or non-globally reachable addresses are used as loopback addresses, this
technique is either not possible, or considerably more complex to
implement.</t>
</section>
<section title="DNS Interaction">
<t>Many ISPs utilise their DNS to perform both forward and reverse
resolution for the infrastructure devices and infrastructure addresses.
With a privately numbered core, the ISP itself will still have the
capability to perform name resolution of their own infrastructure.
However others outside of the autonomous system will not have this
capability. At best, they will get a number of unidentified <xref
target="RFC1918"></xref> IP addresses returned from a traceroute.</t>
<t>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 to
public DNS servers. Further information on this problem is documented in
<xref target="RFC6304">"AS112 Nameserver Operations"</xref>.</t>
</section>
<section title="Operational and Troubleshooting issues">
<t>Previous sections of the document have noted issues relating to
network operations and troubleshooting. In particular when private IP
addressing within an ISP core is used, the ability to easily
troubleshoot across the AS boundary may be limited. In some cases this
may be a serious troubleshooting impediment. In other cases, it may be
solved through the use of alternative troubleshooting techniques.</t>
<t>The key point is that the flexibility of initiating an outbound ping
or traceroute from a privately numbered section of the network is lost.
In a complex topology, with multiple paths and exit points from the AS,
the provider may be restricted in their ability to trace paths through
the network to other ASs. Such a situation could be a severe
troubleshooting impediment.</t>
<t>For users outside of the AS, the loss of the ability to use a
traceroute for troubleshooting is very often a serious issue. As soon as
many of these people see a row of "* * *" in a traceroute they often
incorrectly assume that a large part of the network is down or
inaccessible (e.g. behind a firewall). Operational experience in many
large providers has shown that significant confusion can result.</t>
<t>With respect to RFC1918 IP addresses applied as loopbacks. In this
world of acquisitions, if an operator needed to merge two networks, each
using the same private IP ranges, then the operator would likely need to
renumber one of the two networks. In addition, assume an operator needed
to compare information such as NetFlow/IPFIX or syslog, between two
networks using the same private IP ranges. There would likely be an
issue as the unique id in the collector is, in most cases, the source IP
address of the UDP export, i.e. the loopback address.</t>
</section>
<section title="Security Considerations">
<t>One of the arguments often put forward for the use of private
addressing within an ISP is an improvement in the network security. It
has been argued that if private addressing is used within the core, the
network infrastructure becomes unreachable from outside the providers
autonomous system, hence protecting the infrastructure. There is
legitimacy to this argument. Certainly if the core is privately numbered
and unreachable, it potentially provides a level of isolation in
addition to what can be achieved with other techniques, such as
infrastructure ACLs, on their own. This is especially true in the event
of an ACL misconfiguration, something that does commonly occur as the
result of human error.</t>
<t>There are three key security gaps that exist in a privately addressed
IP core.<list>
<t>The approach does not protect against reflection attacks if edge
anti-spoofing is not deployed. For example, if a packet with spoofed
source address corresponding to the networks infrastructure address
range, is sent to a host (or other device) attached to the network,
that host will send its response directly to the infrastructure
address. If such an attack was performed across a large number of
hosts, then a successful large scale denial of service attack on the
infrastructure could be achieved. This is not to say that a publicly
numbered core will protect from the same attack, it won’t. The key
point is that a reflection attack does get around the apparent
security offered in a privately addressed core.</t>
<t>Even if anti-spoofing is deployed at the AS boundary, the border
routers will potentially carry routing information for the privately
addressed network infrastructure. This can mean that packets with
spoofed addresses, corresponding to the private infrastructure
addressing, may be considered legitimate by edge anti-spoofing
techniques such as Unicast Reverse Path Forwarding – Loose Mode, and
forwarded. To avoid this situation, an edge anti-spoofing algorithm
such as Unicast Reverse Path Forwarding – Strict Mode, would be
required. Strict approaches can be problematic in some environments
or where asymmetric traffic paths exist.</t>
<t>The approach on its own does not protect the network
infrastructure from directly connected customers (i.e. within the
same AS). Unless other security controls, such as access control
lists (ACLs), are deployed at the ingress point of the network,
customer devices will normally be able to reach, and potentially
attack, both core and edge infrastructure devices.</t>
</list></t>
</section>
<section title="Alternate approaches to core network security">
<t>Today, hardware-based ACLs, which have minimal to no performance
impact, are now widespread. Applying an ACL at the AS perimeter to
prevent access to the network core may be a far simpler approach and
provide comparable protection to using private addressing; such a
technique is known as an infrastructure ACL (iACL).</t>
<t>In concept, iACLs provide filtering at the edge network which allows
traffic to cross the network core, but not to terminate on
infrastructure addresses within the core. Proper iACL deployment will
normally allow required network management traffic to be passed, such
that traceroutes and PMTUD can still operate successfully. For an iACL
deployment to be practical, the core network needs to have been
addressed with a relatively small number of contiguous address blocks.
For this reason, the technique may or may not be practical.</t>
<t>A second approach to preventing external access to the core is IS-IS
core hiding. This technique makes use of a fundamental property of the
IS-IS protocol which allows link addresses to be removed from the
routing table while still allowing loopback addresses to be resolved as
next hops for BGP. The technique prevents parties outside the AS from
being able to route to infrastructure addresses, while still allowing
traceroutes to operate successfully. IS-IS core hiding does not have the
same practical requirement for the core to be addressed from a small
number of contiguous address blocks as with iACLs. From an operational
and troubleshooting perspective, care must be taken to ensure that pings
and traceroutes are using source and destination addresses that exist in
the routing tables of all routers in the path. i.e. Not hidden link
addresses.</t>
<t>A third approach is the use of either an MPLS based IP VPN, or an
MPLS based IP Core where the 'P' routers (or Label Switch Routers) do
not carry global routing information. As the core 'P' routers (or Label
Switch Routers) are only switching labeled traffic, they are effectively
not reachable from outside of the MPLS domain. The 'P' routers can
optionally be hidden such they do not appear in a traceroute. While this
approach isolates the 'P' routers from directed attacks, it does not
protect the edge routers - being either a 'PE' router or a Label Edge
Router (LER). Obviously there are numerous other engineering
considerations in such an approach, we simply note it as an option.</t>
<t>These techniques may not be suitable for every network, however,
there are many circumstances where they can be used successfully without
the associated effects of a privately addressing the core.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC1191">
<front>
<title>Path MTU Discovery</title>
<author initials="J" surname="Mogul">
<organization>DECWRL</organization>
</author>
<author initials="S" surname="Deering">
<organization>Stanford University</organization>
</author>
<date month="November" year="1990" />
</front>
</reference>
<reference anchor="RFC1393">
<front>
<title>Traceroute Using an IP Option</title>
<author initials="G" surname="Malkin">
<organization>Xylogics, Inc.</organization>
</author>
<date month="January" year="1993" />
</front>
</reference>
<reference anchor="RFC1918">
<front>
<title>RFC1918 Address Allocation for Private Internets, BCP
5</title>
<author initials="Y" surname="Rekhter ">
<organization>Cisco Systems</organization>
</author>
<author initials="R" surname="Moskowitz">
<organization>Chrysler Corporation</organization>
</author>
<author initials="D" surname="Karrenberg">
<organization>RIPE Network Coordination Centre</organization>
</author>
<author initials="G" surname="Jan de Groot">
<organization>RIPE Network Coordination Centre</organization>
</author>
<author initials="E" surname="Lear ">
<organization>Silicon Graphics, Inc.</organization>
</author>
<date month="Febuary " year="1996" />
</front>
</reference>
<reference anchor="RFC2827">
<front>
<title>RFC 2827 Network Ingress Filtering, BCP 38</title>
<author initials="P" surname="Ferguson">
<organization>Cisco Systems, Inc.</organization>
</author>
<author initials="D" surname="Senie ">
<organization>Amaranth Networks Inc.</organization>
</author>
<date month="May" year="2000" />
</front>
</reference>
<reference anchor="RFC3704">
<front>
<title>Ingress Filtering for Multihomed Networks</title>
<author initials="F" surname="Baker">
<organization>Cisco Systems</organization>
</author>
<author initials="P" surname="Savola">
<organization>CSC/FUNET</organization>
</author>
<date month="March" year="2004" />
</front>
</reference>
<reference anchor="RFC1981">
<front>
<title>Path MTU Discovery for IP version 6</title>
<author initials="J" surname="McCann">
<organization>Digital Equipment Corporation</organization>
</author>
<author initials="S" surname="Deering">
<organization>Xerox PARC</organization>
</author>
<author initials="J" surname="Mogul">
<organization>Digital Equipment Corporation</organization>
</author>
<date month="August" year="1996" />
</front>
</reference>
<reference anchor="BCP38">
<front>
<title>Network Ingress Filtering: Defeating Denial of Service
Attacks which employ IP Source Address Spoofing</title>
<author initials="P" surname="Ferguson">
<organization>Cisco Systems, Inc.</organization>
</author>
<author initials="D" surname="Senie">
<organization>Amaranth Networks Inc.</organization>
</author>
<date month="May" year="2000" />
</front>
</reference>
<reference anchor="BCP84">
<front>
<title>Ingress Filtering for Multihomed Networks</title>
<author initials="F" surname="Baker">
<organization>Cisco Systems</organization>
</author>
<author initials="P" surname="Savola">
<organization>CSC/FUNET</organization>
</author>
<date month="March" year="2004" />
</front>
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC792">
<front>
<title>RFC792 Internet Control Message Protocol</title>
<author initials="J" surname="Postel">
<organization>ISI</organization>
</author>
<date month="September" year="1981" />
</front>
</reference>
<reference anchor="RFC3021">
<front>
<title>Using 31-Bit Prefixes on IPv4 Point-to-Point Links</title>
<author initials="A" surname="Retana">
<organization>Cisco Systems</organization>
</author>
<author initials="R" surname="White">
<organization>Cisco Systems</organization>
</author>
<author initials="V" surname="Fuller">
<organization>GTE Internetworking</organization>
</author>
<author initials="D" surname="McPherson">
<organization>Amber Networks</organization>
</author>
<date month="December" year="2000" />
</front>
</reference>
<reference anchor="RFC5837">
<front>
<title>Extending ICMP for Interface and Next-Hop
Identification</title>
<author initials="A" surname="Atlas">
<organization>BT</organization>
</author>
<author fullname="R" surname="Bonica">
<organization>Juniper Networks</organization>
</author>
<author initials="C" surname="Pignataro">
<organization>Cisco Systems</organization>
</author>
<author initials="N" surname="Shen">
<organization>Cisco Systems</organization>
</author>
<author initials="JR" surname="Rivers">
<organization>Consultant</organization>
</author>
<author>
<organization></organization>
</author>
<date month="April" year="2010" />
</front>
</reference>
<reference anchor="RFC6304">
<front>
<title>AS112 Nameserver Operations</title>
<author initials="J" surname="Abley">
<organization>ICANN</organization>
</author>
<author initials="W" surname="Maton">
<organization>NRC-CNRC</organization>
</author>
<date day="29" month="July" year="2011" />
</front>
</reference>
<reference anchor="RFC6598">
<front>
<title>IANA-Reserved IPv4 Prefix for Shared Address Space</title>
<author initials="J" surname="Weil">
<organization>Time Warner Cable</organization>
</author>
<author initials="V" surname="Kuarsingh">
<organization>Rogers Communications</organization>
</author>
<author initials="C" surname="Donley">
<organization>CableLabs</organization>
</author>
<author initials="C" surname="Liljenstolpe">
<organization>Telstra Corp</organization>
</author>
<author initials="M" surname="Azinger">
<organization>Frontier Communications</organization>
</author>
<date month="April" year="2012" />
</front>
</reference>
</references>
<section title="Acknowledgments">
<t>The author would like to thank the following people for their input
and review – Dan Wing (Cisco Systems), Roland Dobbins (Arbor Networks),
Philip Smith (APNIC), Barry Greene (ISC), Anton Ivanov
(kot-begemot.co.uk), Ryan Mcdowell (Cisco Systems), Russ White (Cisco
Systems), Gregg Schudel (Cisco Systems), Michael Behringer (Cisco
Systems), Stephan Millet (Cisco Systems), Tom Petch (BT Connect), Wes
George (Time Warner Cable), Nick Hilliard (INEX).</t>
<t>The author would also like to acknowledge the use of a variety of
NANOG mail archives as references.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 23:55:20 |