[58937] in North American Network Operators' Group
Re: Best Practices for Loopback addressing (Core routers & VPN CPE)
daemon@ATHENA.MIT.EDU (Haesu)
Fri Jun 6 12:48:59 2003
Date: Fri, 6 Jun 2003 12:47:28 -0400
From: Haesu <haesu@towardex.com>
To: m.rapoport@completel.fr
Cc: nanog@merit.edu
In-Reply-To: <OF7E6A2B7D.47488CEE-ONC1256D2B.0037AC20-C1256D3D.0058779F@LocalDomain>
Errors-To: owner-nanog-outgoing@merit.edu
> However, considering that these loopbacks are only used for routing
> protocols (OSPF,BGP, LDP)
> and for network management (SNMP, telnet, ...) and that these addresses
> don't need to visible from public Internet
> (not seen in traceroute, not seen on Internet BGP announces ...) I am
> considering to
> use private RFC1918 for a new Backbone deployment.
Or, you could use a seperate class C or whatever fits yoru backbone for loopbacks and router interfaces.. Just don't advertise that block. That way you use non-rfc1918 on the backbone, and yet outside people cannot get to it since you dont advertise it to the world... It's just me but i am against using rfc1918 on any part of a backbone.
-hc
>
> N.B. : Assumption is that e-BGP sessions with Internet peers are done on
> public interface IP, not on loopback IP.
>
> Is there some specific case I am missing where public loopback IP is
> required, and therefore
> private adressing would break something (maybe some Carrier-to-Carrier
> scenario ?) .
>
> I also plan to use RFC1918 addresses for Internet CPE routers loopbacks.
>
> 2) Loopback on CPE routers of the MPLS VPN customers.
> For this case, the issue is to assign the adresses in a global range for
> all the CPE of
> all the VPN customers.
> In fact, all these loopback will need to be part of the Network Management
> VPN for supervision needs.
> Using RFC 1918 addresses might create trouble as there is a very high
> chance that the VPN customers
> are already using 1918 addresses, this might generate addresses conflicts.
> Addresses unicity among all the customers is required due to the Network
> Management VPN common
> to all the customers.
> Using public address guarantee unicity, but will create issues with public
> registries, considering that
> these addresses are used for internal needs.
> I am considering to use the 198.18.0.0/15 defined in RFC 2544 and listed in
> RFC 3330 as reserved for
> lab testing.
> I suppose that no VPN customer uses this prefix for its internal IP
> addressing, and as these addresses don't
> need to be announced on Internet.
> Do you suggest to use an other prefix than 198.18.0.0/15 for this purpose ?
>
> If you consider your adressing policy as touchy topic in terms of
> security, don't hesitate to reply in private ...
> Regards,
>
>
--
Sincerely,
Haesu C.
TowardEX Technologies, Inc
WWW: http://www.towardex.com
E-mail: haesu@towardex.com
Cell: (978) 394-2867
