Open Stack

On Tue, Jan 12, 2016 at 11:32 AM, Dan Sneddon <dsneddon at redhat.com> wrote:
> I can confirm that OpenStack doesn't have Carrier Grade NAT (CGN), but
> this RFC simply sets aside a set of addresses which can be used for CGN
> (100.64.0.0/10), and lays out some required and best practices for
> running a CGN network.
>
> I don't see any reason why these addresses couldn't be used. In fact,
> giving RFC 6598 a readthrough it appears that Neutron NAT would fulfill
> the requirements of this RFC, as long as 100.64.0.0/10 were only used
> for Tenant networks and not floating IP addresses.
>
> That said, we already have 192.168.X.X, 172.X.X.X, and 10.X.X.X
> addresses. If a customer were already using all of these throughout
> their network, then I could see using 100.64.0.0/10 in order to have
> unique addresses within the OpenStack deployment.

I'd discourage the use of 100.64.0.0/10 for any tenant networks.
Quoted the RFC [1]:  "This address block will be called the "Shared
Address Space" and will be used to number the interfaces that connect
CGN devices to Customer Premises Equipment (CPE)." and "In particular,
Shared Address Space can only be used in Service Provider networks or
on routing equipment that is able to do address translation across
router interfaces when the addresses are identical on two different
interfaces."  It isn't spelled out clearly, but this hints at only
using these addresses on infrastructure devices used in service
providers' networks.  The closest this would get to a customer is
assigning the router at the customer's edge an address from this range
(like your home router's external address).  These devices pass
packets and use the shared address space to communicate with other
devices in the service provider's network but these addresses are
never seen by the end user in the packets that reach their devices.

If tenants and other people in general start getting the idea that
these addresses are just a fresh allocation of new RFC 1918 equivalent
addresses and they start using them then this will limit availability
for the infrastructure networks where they were meant to be used.
This defeats the purpose for allocating this space.

Don't use these addresses on your home, corporate or other networks
thinking that this is just an addition to the existing RFC 1918
addresses!  This address space can be used carefully to reduce
pressure or your address space but use it properly, please.  Use it
for your routers and other infrastructure to talk to each and other
isolated, confined areas but don't expose these addresses to your
end-users and be sure the scope where these addresses are viable
within your organization's network is strictly limited.

If you strictly use NAT between the tenant networks and the rest of
the network, then it is isolated but I still worry about exposing the
addresses to tenants.  It is a small step to go from this to using
100.64.0.0/10 addresses by the customer in other places (for example,
customer wants a VPN to their tenant network).  Pretty soon, the
customer is using the address space on their own in a way that
conflicts with a provider and we're back at square one.  Service
providers should always have the right-of-way with this space.

My $0.02

Carl

[1] https://tools.ietf.org/html/rfc6598#section-1