Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

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

Re: rfc 1918?

  • From: Greg A. Woods
  • Date: Thu Feb 22 18:52:57 2001

[ On Thursday, February 22, 2001 at 17:33:53 (-0500), John Hawkinson wrote: ]
> Subject: Re: rfc 1918?
>
> > > > There are good reasons to want to get those packets (traceroutes from
> > > > people who have numbered their networks in rfc1918 networks,
> > 
> > No John, there are exactly zero reasons, good or otherwise, for allowing
> > any traffic with RFC-1918 source addresses to traverse any part of the
> > public Internet.  Period!  :-)
> 
> You are being religious, and I shall not descend into this sort of
> discussion with you. It is simply non productive nor professional.

OK, sorry, let me qualify that:

No John, there are exactly zero TECHNICAL reasons, good or otherwise,
for allowing any traffic with RFC-1918 source addresses to traverse any
part of the public Internet.  Period!  :-)

> I disagree, and believe that other reasonable people do so as well,
> and there is therefore argument over this issue. People should not
> assert canonicity upon it. End of story.

In all of the past discussions on this issue there have never been any
presentations of technical reasons for allowing RFC-1918 addresses (in
either the source *or* destination fields) to traverse the public
Internet.  (At least none have been presented while I've been watching,
not anywhere.)

Yes those who have the misunderstanding that they can use such addresses
are going to fail to filter them lest they block their own uses, but
that's circular reasoning, even if it is technically correct within the
microcosms of those people's own minds.

However in public there is no possible valid technical argument, by mere
definition of the way RFC-1918 defines the fact that such addresses are
solely for PRIVATE use, and private use ONLY.  Unfortunately RFC-1918 is
not also a STD-* document, but even as it is just a Best Current
Practice, it can only ever really succeed even as a BCP if everyone
co-operates completely, and since people are eager to use PRIVATE
addresses that pretty much forces the rest of you to co-operate since
we're going to filter the heck out of your "mis-uses".

RFC-1918 also clearly suggests that non-unique PRIVATE addresses are
really only useful where external connectivity is not used -- i.e. for
private networks that are never in any way connected to the public
Internet.  I.e. use of private addresses on public devices, with or
without filtering at network borders, is still "wrong".  One might even
go so far as to argue that use of PRIVATE addresses behind a proper NAT
is similarly "wrong", though of course with a proper NAT you'd never
know!  :-)

Note that any part of the Internet which joins any two independently
controlled and operated nodes is, by definition, public.  That means
that even an ISP with just direct customers must still never allow
RFC-1918 addresses to appear at either their customer sites, or on their
back-haul(s) to the rest of the Internet.  Their customers have just as
much right to make private use of RFC-1918 addresses as does any other
participant on the public Internet.  Any use by any ISP of any RFC-1918
addressing violates that right.

The only other technical option is to forget about allocating private
address space, deprecate RFC-1918, and open up the address space to full
and proper routing.  Though I do find private address space handy, I
wouldn't mind making all that space publicly available too.  So, do we
want RFC-1918 promoted to a full standard, or deleted?  You choose.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>





Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.