[arin-ppml] Ending point to point links as a justification for a /30?

[William Herrin]

On Thu, Jul 29, 2010 at 11:45 AM, Richard A Steenbergen
<ras at e-gerbil.net> wrote:
> On Thu, Jul 29, 2010 at 10:49:27AM -1000, William Herrin wrote:
>>
>> Okay, so let's forget writing policy to this at the moment. Absent any
>> policy change, would anybody encourage/object to the ARIN board
>> issuing an open letter to the routing vendors to the effect of:
>>
>> "As you know, we're running out of IPv4 addresses. To help mitigate
>> the shortage, we respectfully ask you to implement features in your
>> software which enable and encourage your customers to employ RFC1918
>> IP addresses within their routing infrastructure. Such features might
>> include:
>>
>> icmp-response interface loopback0
>>
>> Originate ICMP warnings and errors for packets received on this
>> interface using the IP address assigned to Loopback0.
>
> There is this little tool out there called "traceroute", you might have
> heard of it. Some of us like it, as it helps keep the Internet running.
> Please don't encourage people to break it just to try and save a handful
> of IP addresses.

Hi Richard,

One of us misunderstands the situation. Let's back up and talk about
how traceroute works, the character of the problem encountered when
traceroutes are attempted via routers configured with RFC1918
addresses and how the proposed technology attempts to address the
problem.

Briefly, traceroute works by sending packets with the TTL byte in the
IP header intentionally set too low to reach the destination. This
byte is decremented by each router the packet passes through. When it
hits zero, the router is not allowed to pass it on. It must instead
respond with an ICMP type 11 packet - time exceeded.  So, it builds an
ICMP packet using the original packet's source as the ICMP packet's
destination and using the router's interface address on which the
offending packet was received as the source address. It appends as
much of the original packet as it wants to (at least 64 bytes worth if
I remember right. Might have been 56). And then it sends this new
packet on back to the source of the too-short TTL packet.

When the traceroute program receives this type 11 ICMP message, it
matches the packet it sent with the one included in the ICMP message
and notes that the router which sent the packet is so-many hops away.
So, in a nutshell, that's how traceroute works.

Traceroute works exactly the same way when one of the routers is
configured with RFC1918 addresses, but there's a hitch: at many system
borders, packets containing an RFC1918 source address (such as the
ICMP message the router constructed) are firewalled - not allowed to
pass. They're only legitimate source addresses within the system, not
beyond it. As a result, the ICMP packet never makes it back to the
traceroute program and you see three slow stars.

Under the hood there's actually a much more serious problem - ICMP
type 3 messages (destination unreachable) also don't make it back. TCP
needs ICMP type 3 code 4 messages (fragmentation needed) to work
properly, so you unexpectedly find yourself unable to pass data with
HTTP and SMTP over paths that include that router. You drop your MTU
to 1400 and viola, the problem magically disappears because the
packets are now small enough to get past that router.


Now, let's talk about how "icmp-response interface loopback0"
addresses this problem. The basic idea is this: you configure
interface loopback0 with a global IP address (e.g. 199.33.225.1). Then
you configure your interfaces with RFC1918 addresses (e.g.
192.168.100.125/30). Now, the router receives a packet with a TTL of 0
(from a traceroute). Ordinarily, it would construct the ICMP message
with a source address of 192.168.100.125. That would get blocked by
the firewall. But this router is programmed with "icmp-response
interface loopback0" so instead of using the interface address it
originates the ICMP packet from loop0's address: 199.33.225.1. The
ICMP packet with a soruce address of 199.33.225.1 makes it all the way
back to you since it's a legitimate source address for that network
and you see a router hop at 199.33.225.1, a legitimate global address
for that router.

All without burning global addresses on each separate point to point
interface on the router.

See how that works?

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004