Re: Ipv6 help

[Brandon Martin <lists.nanog () monmotha net>]

On 8/26/20 4:49 AM, Bjørn Mork wrote:
> You aren't forcing anything if you allow the users to use any CPE and
> document the features it must/should have.
>
>   You want IPv4 access without DNS? Then you need CLAT
>   You don't know what CLAT is?  Call your CPE vendor for support
>   You don't care what CLAT is?  Use our CPE
>   You want to call us for support?  Use our CPE
>
> There is no force here.  It all is pretty similar to
>
>   You want to connect the CPE to our ONT?  Then you need Ethernet
>   etc.
>   
> excluding all those TokenRing routers.

I don't force them to.  I was countering the other arguments up-thread 
from folks who do so, and I understand why they do.

I'd say easily 90% of my customers take my offered RG-CPE without any 
questions whatsoever - they in fact have come to expect that I provide one.

Of the remaining 10%, easily half or more of them are satisfied with the 
RG-CPE I provide after I explain a few things about it (and I have a 
cut-sheet for the support folks to do so where applicable).  They mostly 
want to know that it's not a braindead piece of crap presumably because 
they've had bad experiences in the past with SP-provided RG-CPEs (e.g. 
AT&T U-Verse).

It's the remainder I'm talking about.  It's almost all "power users". 
but even where they do have a fairly firm grasp of basic and even 
moderately advanced home/SMB networking, they're often unfamiliar with 
SP-side features that have cropped up and start to burden the routers 
such as IPv6-IPv4 transition features.  This is what I'd like to address 
in a more streamlined manner.

To wit:

> > It would be nice if the consumer router industry could get its
> > collective act together and at least come up with some easy-ish to
> > understand feature support table that customers can match up with
> > their service provider's list of needs.

> If you create such a feature table as the service provider, and the
> customer is unable to match it against their CPE documentation, then
> that's a problem between the CPE vendor and the customer.
>
> I can't understand why you want to make it your problem, as long as you
> offer a CPE that just works.

I would LOVE to be able to just create such a required features table. 
The issue is that there are virtually no retail (even niche online 
channels) CPE devices that clearly document their capabilities to match 
up with my feature table.  That's what I'm whinging about that the 
retail RG-CPE industry really should address, IMO.

I can adopt best practices to make sure I provide configuration info via 
the proper DHCP(v6) options, attempt to delay making such features 
mandatory by providing e.g. NAT444 fallback, etc. as long as possible, 
etc., but eventually, people are going to have to migrate to equipment 
that supports these more modern features or be left behind, and, right 
now, it's very tough to even identify whether a device you're looking at 
in Best Buy or WalMart supports them or not (leaving aside the fact, for 
now, that the answer is often "it doesn't").

So, I'm left with the "do what works" option of attempting to enumerate 
models known to work.  Nobody likes this.  Customers feel like they're 
unnecessarily constrained, and service providers have to maintain that 
list and deal with questions about it for something that should be 100% 
a customer decision.

Or, I can just say "You have to use our RG-CPE otherwise you're on your 
own and I can't guarantee anything useful will even work.", and that's 
not a good way to sell service to the handful of generally outspoken 
customers who do want to do things their own way.
--
Brandon Martin