Implementing IPv6 in a SP environment - Multiple Customer prefixes

[fmenezes]

Consider a IPv4 SP that hosts customers Servers/WebSites.

Today this SP has a LAN dedicated to these "SMB" clients, all "promiscuos" on the same LAN.

Each customer has one IPv4 address, and can (via PAT) serve more than a physical "backend" Server.

The SP thus gives "hosting" to potentially 1000+ customers on the same box.

This SP is now considering IPv6, and wishes to mantain the same architecture.

since there is no adress space issue with IPv6 and NAT/PAT is not supported he wants to give a /64 prefix to each customer.

But... how can he route towards these /64 subnets?

I see there options:

1. Static Routes. But... is really advisable to place 1000+ static IPv6 routes on a single router?? (it is a N7K by the way)

2. Dynamic Routing. But... this means that the customer is "forced" to have a Router with Dynamic Routing Capabilities.

3. Prefix Delegation. (I'm not familiar with this one). But... can the customer assing a "static" IP to a server in the backend with a "delegated" prefix?

4. I don't see a 4th hypotesis, but I'm sure someone does!

Any idea is welcome,

Francisco

(I'm adding a diagram)

[jsmall123]

For customers just hosting a single server, why don't you use a routed port?  You can then do SLAAC or DHCPv6.  The customer can use those or elect to use a static address from the /64.  Since this is directly connected you don't need additional routing.  You can summarize the /64s when you advertise routes to neighboring devices.

For customers that want their own router/firewall use a /64 for the link from your 7k to their CPE.  Then assign them a /64 or /60 or whatever you arrange.  For that I would use a static route to the CPE again making sure to summarize.  For a small setup like your describing I wouldn't use an IGP.  This doesn't fit with the customer type you're describing.

My impression of DHCP-PD is its more targeted for residential/SMB customers and not hosting environments.

--Jim

[fmenezes]

Hi Jim,

thank you very much for your post!

You hit the issue...

I agree with you, the solution for the "one server" customer is the "connected" subnet, so no further entries are needed there.

The issue is in fact for the /64 backend subnets of the other customers. I think I was not clear before, the scenario is not a small setup, but we have thousands of these customers that are now attached to the same Router (in IPv4). The diagram is just an example, multiply the customers on the diagram by a 500 factor.

Let's consider 1500 customers. Today they are all in the same frontend subnet, "hiding" their backend subnets via IPv4 PAT.

Now we are migrating to IPv6 and we are giving 1500 /64 subnets that the customer can use on his backend.

The question is: what is the best way to reach there 1500 backend subnets?

Placing 1500 static routes might work, but it does not seem a very nice/elegant solution.

Moreover I wonder if a config file this large could give any kind of issue, or if the Nexus could suffer due to the number of IPv6 routes it would have to handle.

You still advise the "static" approach?

Francisco