North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: rfc 1918?

  • From: Greg A. Woods
  • Date: Fri Feb 23 14:04:30 2001

[ On Friday, February 23, 2001 at 08:46:00 (-0600), Mark Borchers wrote: ]
> Subject: RE: rfc 1918?
>
> 
> Unless I'm mistaken, a prime reason for the evolution of RFC 1918
> addresses was that it was once common practice for people to
> help themselves to PUBLIC address space to use on PRIVATE
> networks.  As the world got more connected, these addresses
> occasionally got leaked and caused address conflicts.  

Indeed, which is what I was alluding to when I said I still know of
several private networks using public address space.

> Using RFC 1918 addresses prevents conflicts with public/registered
> space.  Obviously the possibility of leakage still exists,
> but with RFC 1918 the havoc potential is diminished to a mere
> irritant level.  Which is what the incident that started this
> thread appeared to be.

Well, it depends on just how much of an ierritant it gets to be.

If you agressively filter all RFC-1918 addressed packets at your borders
because you use such addresses internally and don't want any spoofing to
happen, but then your users start complaing because they have traceroute
problems, Path-MTU-discovery problems, etc., etc., etc., etc., then it
starts to look a lot more like general havoc again.

Either people have to really use RFC-1918 private address space properly
and ensure it never ever leaks (and maybe even some core locations have
to start filtering it where they can just to provide the helpful service
of helping correct other people's mistakes), or we have to give up on
using common private address space completely.  When providers treat
their public transit links as if they were part of an internal network
for this purpose thing are way out of hand.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <[email protected]>      <robohack!woods>
Planix, Inc. <[email protected]>; Secrets of the Weird <[email protected]>