Which makes (or made) the case for vCPE. You don’t need to truck-roll. All the smarts happen in the data centre. Agreed. Whether you go vCPE and upgrade all your customers in one go without truck-rolling, or if you actually truck-roll and replace the CPE with those which support CLAT, it makes technical and commercial sense vs. having to deal with IPv4 and CGN’s. Mark.
My experience is that the room of folk that prefer to run their own CPE
is far less full than the ones who don't.
So outside of some power users (who probably run a network of some
kind), this isn't going to be a huge problem.
Mark.
At some point, you run out of IPv4.
You could cascade to a high degree of NAT444, but then it gets hairy,
and costly, at some point.
Mark.
This is why we wrote RFC8585, so users can freely buy their own router ...
The ISP can also list some of the compatible models in case they are using "additional" features.
El 25/8/20 22:16, "NANOG en nombre de Brandon Martin" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de lists.nanog@monmotha.net> escribió:
> This is very common in many countries and not related to IPv6, but
> because many operators have special configs or features in the CPEs they
> provide.
I really, really hate to force users to use my network edge router (I
provide the ONT, though, and I provide an edge router that works and
most users do take it), but it can be tough to ensure users have
something that supports all the right modern features and can be
configured via standard means.
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. The status quo of a list of devices
that work right (which is of course often staggeringly short if you're
doing any of these modern transition mechanisms) that needs constant
updating and may not be easily available is not ideal.
Heck just having a real, complete list of supported features on the
model support page on their website would be an improvement...
No, this doesn't work
The point your're missing (when I talked before about putting all the costs to make a good calculation of each case and then replacing CPEs become actually cheaper) is that you need more IPv4 addresses in CGN than in NAT64 and further to that, in CGN, your IPv4 pools sooner or later become blocked by PSN (unless you don't have gammers among your customers).
El 25/8/20 22:42, "NANOG en nombre de Brian Johnson" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de brian.johnson@netgeek.us> escribió:
I usually solve this problem by designing for NAT444 and dual-stack. This solves both problems and allows for users to migrate as they are able/need to. If you try and force the change, you will loose users.
How doesn’t it work? As long as IPv6 is *on* NAT444 + dual stack has the same properties (or better, less PMTUD issues) as turning on 464XLAT in the CPE. Traffic shifts to IPv6 due to hosts preferring IPv6. You can still disable sending RA’s in either scenario.
Mark
It was a way to say.
Because you use IPv4 pools in the CGN. Then when detected by some services such as PSN, they are black-listed. You use other pools, they become black listed again, and so on.
This is not the case with NAT64/464XLAT.
So yeah, it works but the cost of purchasing CGN is actually becoming higher and you will need sooner or later, to buy more IPv4 addresses once all them are black-listed.
I've not heard about anyone that has been able to convince Sony to clean their addresses from the PSN CGN black-list.
El 26/8/20 9:07, "Mark Andrews" <marka@isc.org> escribió:
How doesn’t it work? As long as IPv6 is *on* NAT444 + dual stack has the same properties (or better, less PMTUD issues) as turning on 464XLAT in the CPE. Traffic shifts to IPv6 due to hosts preferring IPv6. You can still disable sending RA’s in either scenario.
Mark
Brandon Martin <lists.nanog@monmotha.net> writes:
This is very common in many countries and not related to IPv6, but
because many operators have special configs or features in the CPEs
they provide.I really, really hate to force users to use my network edge router (I
provide the ONT, though, and I provide an edge router that works and
most users do take it), but it can be tough to ensure users have
something that supports all the right modern features and can be
configured via standard means.
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.
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.
Bjørn
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 CPEThere 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.
To be fair, most customers don't care about features.
A customer will buy an 802.11ax wi-fi router, completely forgetting that
their demarc. CPE is ADSL or only good for 25Mbps FTTH.
A customer will want to stream at 4K from their in-home DLNA server,
connected to a wi-fi adapter, and totally forget that that wi-fi adapter
only talks 802.11b. Or better, they'll have an 802.11ac wi-fi adapter in
their DLNA server, but forget that the AP it's talking to is only
connected at 10Mbps to the LAN.
This stuff was easier when customers had dial-up or ADSL. It's going to
get a lot more complicated to fully appreciate with FTTH, because most
customers don't understand that the performance of any link is limited
by the weakest one all the way from the user device, into their (W)LAN,
and up to the package they bought from their ISP.
So publishing features for a CPE for customers to buy won't work for the
majority of folk. All they'll look at is, "Does it say Wi-Fi Router",
has the Wi-Fi logo, pay, and leave. And the attendants in the shop are
neither the wiser nor have the patience to clue Jane or Joe on proper
home network design.
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 don't want a customer calling me anymore than the next ISP does. But,
when a customer has a problem, they won't pick up the phone and call
D-Link, TP-Link or Linksys. They'll call me, their provider. And this is
true whether they got the CPE from me or by themselves from a store.
We need to think outside of this NANOG group of nerds...
Mark.
Over sub at around 20-40 to 1 is very easy now. With PBA, DET-NAT and other tools, the average customer largely doesn’t know it is happening and it solves for many provider side issues as well (logging being the biggest). For those customers who have issues, the over-sub ratios leave IPv4 space for those corner cases and/or native IPv6 should be made available.
And before anyone yells that this "breaks something,” It was already broken.
I’ve not experienced this with PSN and NAT444. I have a LOT of customers doing it without issue. Maybee it’s that the customer has native IPv6 and solves for the problem that way, but then this just becomes make sure IPv6 is provided and it solves for the corner case.
I'll dedicate my time to limited flexing with CPE vendors on
implementing CLAT, thanks :-).
If that doesn't work for me in the short term, hopefully, it will help
someone else in the long run.
Mark.
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 CPEThere 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.
It's a great RFC. Hopefully it continues to gain traction.
Do you know of a single router available in the US (or even broader North American) retail market that has "RFC8585" printed anywhere on the outside of the box or even in the documentation one might actually consult pre-purchase? I would love to evaluate it (or, even better, a few of them) to ensure I'm compatible on the provider side with how the equipment makers have interpreted the RFC! Then I can also have some specific models to direct people toward along with "Or just look for 'RFC8585' on the box".
But, right now, I am aware of none.
The crazy thing is that PSN doesn't (up to my knowledge) yet work with IPv6 ... but I understand that when several players are behind the same CGN, games don't work as expected (may be not all them). So, Sony decided long time ago to ban forever, any CGN IPv4 pools that they detect on that situation. It is not something that happens "immediately" you have a CGN, but I'n aware of several customers that got into that situation.
Not just Sony, other services are doing the same. I heard about OpenDNS cases as well.
El 26/8/20 16:42, "Brian Johnson" <brian.johnson@netgeek.us> escribió:
I’ve not experienced this with PSN and NAT444. I have a LOT of customers doing it without issue. Maybee it’s that the customer has native IPv6 and solves for the problem that way, but then this just becomes make sure IPv6 is provided and it solves for the corner case.
I work and I'm in touch with many CPE vendors since long time ago ... many are on the way (I can remember about 12 on top of my head right now, but because contracts, can't name them). It takes time. However, in many cases, they just do for specific customers or specific models. I know other people that contacted the same vendors and they told them "we could do it for the model you use as well". In some cases, they require a minimum volume per year (less than what you could expect. I've seen cases that start with just 500 units per month).
But this only works if you contact them. The CPE vendors business model seems to be very "ISP" direct. I think the retail marked models, unfortunately, will take a bit more time.
A hint about some vendors: You may take a look at the co-authors in the RFC.
El 26/8/20 18:30, "NANOG en nombre de Brandon Martin" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de lists.nanog@monmotha.net> escribió:
> This is why we wrote RFC8585, so users can freely buy their own router ...
It's a great RFC. Hopefully it continues to gain traction.
Do you know of a single router available in the US (or even broader
North American) retail market that has "RFC8585" printed anywhere on the
outside of the box or even in the documentation one might actually
consult pre-purchase? I would love to evaluate it (or, even better, a
few of them) to ensure I'm compatible on the provider side with how the
equipment makers have interpreted the RFC! Then I can also have some
specific models to direct people toward along with "Or just look for
'RFC8585' on the box".
But, right now, I am aware of none.
To this day, my PS4, running Sony's latest code, does not support IPv6.
That might be a good place to start, for them.
At the rate they are doing, the PS5 might ship with RIPv2.
Mark.
This sounds like a Sony problem more than a network problem. They need to get on the IPv6 train and play nice with the Internet. X-BOX has had IPv6 support since X-BOX One.
IIRC, someone here said the issue wasn't so much PS4 (which runs
FreeBSD-9.0), but the PSN back-end.
I can believe this, as Sony TV I bought back in 2015 had IPv6 support,
on their own embedded OS.
Mark.
This is the bit I was referring to when I meant, "It shouldn't be this
hard".
It's one thing for big San Jose vendors to build boxes for specific
customers based on volume or deal potential. It's another when consumer
CPE's do not get critical love like CLAT until some large provider with
millions of customers that is half-interested in spending some energy on
this walks up dangling a potential cheque in front of them.
If these CPE vendors are here, lurking, don't waste your time developing
WMM for your wireless routers. Divert those resources to implementing
CLAT rather. Customers are more likely to buy CPE if they perform the
most basic functions well. Heck, half the work has already been done in
OpenWRT...
Mark.