[48546] in North American Network Operators' Group
Re: Bogon list
daemon@ATHENA.MIT.EDU (Stephen Griffin)
Thu Jun 6 18:35:31 2002
In-Reply-To: <20020604234928.D536CC7936@cesium.clock.org> from "Sean M. Doran" at "Jun 4, 2002 04:49:28 pm"
To: smd@clock.org (Sean M. Doran)
Date: Thu, 6 Jun 2002 18:34:48 -0400 (EDT)
From: Stephen Griffin <stephen.griffin@rcn.com>
Cc: nanog@merit.edu
Errors-To: owner-nanog-outgoing@merit.edu
In the referenced message, Sean M. Doran said:
> Basically, arguing that the routing system should carry around
> even more information is backwards. It should carry less.
> If IXes need numbers at all (why???) then use RFC 1918 addresses
> and choose one of the approaches above to deal with questions
> about why 1918 addresses result in "messy traceroutes."
>
> Fewer routes, less address consumption, tastes great, less filling.
>
> Sean.
Do you:
1) Not believe in PMTU-D
2) Not believe in filtering RFC1918 sourced traffic at enterprise boundaries
(of which an exchange would be a boundary)
3) Not believe packet-passing devices have legitimate needs in contacting
hosts, even if hosts don't have legitimate needs for contacting them? (a
superset of 1, above)
4) All or some of the above?
I would love if RFC1918 were adhered to such that L3 packet-passing devices
either weren't numbered out of those blocks, or allowed what juniper allows
with the ability to select the ip address with which packets sourced by
the L3 packet-passing device sent traffic (other than primary ip on
destination interface). The latter would permit intra-enterprise use
of RFC1918 addresses, while still conforming with RFC1918. Failing that,
use of RFC1918 addresses in places where inter-provider packets get
RFC1918 sources, is a violation of RFC1918.
In any event, exchanges are inter-enterprise, and shouldn't be RFC1918.
