[86832] in North American Network Operators' Group
Re: IAB and "private" numbering
daemon@ATHENA.MIT.EDU (Mark Smith)
Thu Nov 17 15:17:36 2005
Date: Fri, 18 Nov 2005 06:44:49 +1030
From: Mark Smith <random@72616e646f6d20323030342d30342d31360a.nosense.org>
To: Daniel Karrenberg <daniel.karrenberg@ripe.net>
Cc: Michael.Dillon@btradianz.com, nanog@nanog.org
In-Reply-To: <20051117164410.GB17195@91.18.1.10.in-addr.arpa>
Errors-To: owner-nanog@merit.edu
On Thu, 17 Nov 2005 17:44:10 +0100
Daniel Karrenberg <daniel.karrenberg@ripe.net> wrote:
> On 15.11 07:38, Mark Smith wrote:
> >
> > RFC1627, "Network 10 Considered Harmful (Some Practices Shouldn't be
> > Codified)" and RFC3879, "Deprecating Site Local Addresses" provide some
> > good examples of where duplicate or overlapping address spaces cause
> > problems, which is what happens when different organisations use RFC1918
> > addresses, even if they aren't connected to the Internet.
>
> This is practical engineering, not theoretical science. Practical
> engineering is about *trade-offs*.
>
All I know is that I've had bad experiences with duplicated or
overlapping address spaces. One particularly bad one was spending two
months developing templates for combinations of NAT / NAPT for Internet
/ VPN access (e.g. NAT to Internet, not VPN; NAT to VPN, not Internet;
NAPT to Internet, NAT to VPN, different "to" address spaces for NAT to
the Internet and NAT to the VPN etc. etc.). In addition to developing
these solutions I also sat scratching my head for two months asking "why
not just give them public address space, restoring uniqueness to their
addressing, so I can work on improving the product rather than just
developing work arounds ?". Spending time on work arounds, as well as
building protocol and other limitations into the network that will be
encountered in the future, isn't a good trade-off in my
opinion.
Regards,
Mark.
--
"Sheep are slow and tasty, and therefore must remain constantly
alert."
- Bruce Schneier
