Re: IAB and "private" numbering

From: Mark Smith (no email)
Date: Thu Nov 17 2005 - 15:14:49 EST

  • Next message: Evaldo Gardenali: "Re: Someone from nic.net registrar please contact me off-list"

    On Thu, 17 Nov 2005 17:44:10 +0100
    Daniel Karrenberg <> 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
    

  • Next message: Evaldo Gardenali: "Re: Someone from nic.net registrar please contact me off-list"





    Hosted Email Solutions

    Invaluement Anti-Spam DNSBLs



    Powered By FreeBSD   Powered By FreeBSD