end user assignment best practice

[Wade Roberts]

On 2013-03-19, at 5:12, Ron Vachiyer <proutfoo at outlook.com> wrote:

> We are looking at our model for deploying IPv6 /48 prefixes to end sites.  Currently, we are suppying a /29 or /30 IPv4 subnet, and the end customer provides a router/firewall that typically will be doing NAT.  We supply a customer edge device that utilizes the first IP of the v4 subnet assigned to the customer on the "LAN" interface, and the "WAN" interface is numbered with RFC 1918 space.  This allows us to have one numbered interface and one static route per customer.
> 
> In the case of an IPv6 prefix, the "WAN" interface of the device we provide will be using a /64 prefix taken from a pool set aside for loopbacks.  Is it acceptable practice to number the "LAN" interface using a /64 taken from the /48 assigned for the customer, or is it current practice to use a second /64 outside of the /48 to route the /48 to customer equipment?  In other words, in a scenario such as this, are we to provide [/64 + /64 + /48] or [/64 + (/48 - /64)] to the end site?
> 
> Thanks for any input or RTFM material on the subject,
> 
> Ron

Ron,

I'm aware of 4 options.

1. Provide a separate /64 from a pool local to the PE router. A /48 allocated for this caters for ~64k endpoints per PE router. Keeping this local to the PE router prevents route disaggregation within your core, but must be considered dynamic by the CE.

2. Provide an extra customer specific /64. Only viable method today if you require static publicly routable addressing on the WAN side of the CE. Adds an extra routing entry and update if CE can't be guaranteed to terminate on a specific PE router.

3. Steal a /64 from the delegated /48 using RFC 6603. This is not very viable today unless you have strict control over the CE devices as implementations of 6603 are extremely rare.

4. Leave the WAN link to only use Link-Local. Messy and not at all ideal, but works in some situations.

I'm familiar with active deployments which are using options 1 and 4.

I personally don't see the need for RFC 6603 until providers actually begin to encounter exhaustion, but it's worth baking into requirements now so vendors implement it in time.

One problem with RFC 6603 as it currently stands is it's a tool intended for the PE side to dictate the subnet to be excluded from the PD. I'd like to see it updated to allow the CE to use it as a hint to the PE of its preferred excluded subnet. Absent this ability, I'd suggest using the last subnet (FF for /56, FFFF for /48) as the default. Include wording in the agreement with the subscriber to this effect, fix it in layer 8.

As for reading material, TR-187 is worth being familiar with, especially for v6 over PPP:
http://www.broadband-forum.org/technical/download/TR-187.pdf

--
Wade
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20130319/ff705519/attachment.html