Re: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers

[Wuyts Carl <[e-mail]>]

Hi Victor,

Agree.  I do always recommend our customers to assign /56.  This doesn't mean it is always being deployed like this of course, we have single /64s as well.  But this is better for the sake of future proof and leaves some room for expansion without having to fiddle in the back-end to aggregation etc.
The point I want to make is that the req of checking "too small" serves no goal, as nearly all CPE devices have a similar set of interfaces, of which some are used separately, mostly not, some have public wifi, mostly not, etc.  It just makes customers asking questions on it, as they base themselves upon this RFC to send their reqs to CPE vendors.  Moreover, too small (too big too ??) is too much subject of interpretation.

Regs
Carl


From: Victor Kuarsingh [mailto:[e-mail]]
Sent: maandag 25 november 2013 15:57
To: Wuyts Carl
Cc: [e-mail]; [e-mail]
Subject: Re: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers



On Mon, Nov 25, 2013 at 9:39 AM, Wuyts Carl <[e-mail]<mailto:[e-mail]>> wrote:
Hi,

A typical CPE has 4 eth ports and wifi, all joined together as ... the LAN intf, hence 1 interface it is.  You do not hand out different prefixes to wired and wireless.  In fact, you can of course, but this would lead to routed traffic

Carl,

In your case above, I am not sure if the Eth ports you are referring to are separate logical interfaces which are just bridged together or if they are just switch ports that connect back to a single logical interface.  Notwithstanding this, could you not consider all logical interfaces (regardless if they are bridged day-1) as separate for the purposes of asking for IPv6 PD space?

Lets assume that you have 4 eth ports, and standard WiFi interface and a Guest WiFi.  This sounds like 6x [potential] interfaces, of which you may only be using 1-2 for now [say LAN/WiFi is one, and Guest WiFi is two).  If you ask for IPv6 PD space for all of the potential interfaces, rounded up to the nearest nibble, you would grab a ::/60.

So in the beginning, you only configure 2 ::/64s for the interfaces you fire up.  If you expand this and/or break out the function later, then you use more (out of the ::/60).  If you only got a ::/62 or ::/64 from the operator, then you log an error (right)?  If you get a ::/60 or ::/56 you are ok (right)?

regards,

Victor K






Regs
Carl

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>]
Sent: maandag 25 november 2013 15:27
To: Wuyts Carl
Cc: [e-mail]<mailto:[e-mail]>; Victor Kuarsingh
Subject: Re: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers

<snip>

> De : Wuyts Carl <[e-mail]<mailto:[e-mail]>>
> Indeed, this will not be always known upfront.

Carl, could you please give an example where a router doesn't know
upfront the number of interfaces? Even if some of them could be
off at some point (Wifi for example), the router usually knows
the maximum number of local interfaces it can support.

> Besides that, if you
> purely want to look at all active interfaces, I believe you will be
> (for residential market at least) push for a /64 for all
> deployments, and I don't believe this should be the goal.  After
> all, many residential scenario's at our customer base are a single
> LAN from defs....

I don't see why this would push /64 in the residential market.
Most recent routers are expected to have a few interfaces (one
for public wifi and another for the private lan for example) and
therefore should hint for a /60 at least. If DHCPv6-PD is supported
on the LAN side, a hint for /56 or /48 would be expected.

And a hint is just that, a hint. The operator is free to hand out
larger prefixes. Some operators will hand out a /64 in the
absence of a hint because of a number of broken old implementations
unable to carve out /64s out of larger prefixes. But beside these,
/56 or larger is expected to become the standard for residential.

As a data point, we hand out /56s by default as a cable
operator and it works fairly well so far.

/JF