Re: Ipv6 help
This one is the published version: https://datatracker.ietf.org/doc/rfc8683/ El 27/8/20 8:10, "NANOG en nombre de Mark Tinka" escribió: On 27/Aug/20 07:58, Bjørn Mork wrote: > Because NAT64 implies DNS64, which avoids NATing any dual stack service. > This makes a major difference today. NAT64/DNS64 was the original solution. 464XLAT is the improved approach. See: https://tools.ietf.org/id/draft-ietf-v6ops-nat64-deployment-04.html Mark. ** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
Re: Ipv6 help
> On 27 Aug 2020, at 15:58, Bjørn Mork wrote: > > Brian Johnson writes: > >>> 1) It needs *much less* IPv4 addresses (in the NAT64) for the same number >>> of customers. >> >> I cannot see how this is even possible. If I use private space >> internally to the CGN, then the available external space is the same >> and the internal customers are the same and I can do the same over sub >> ratio under both circumstance. Tell me how the math is different. > > Because NAT64 implies DNS64, which avoids NATing any dual stack service. > This makes a major difference today. Only if you don’t have a CLAT installed and for home users that is suicide at there is too much IPv4 only equipment. What really pushes traffic to IPv6 is that hosts prefer IPv6 by default. This works as long as the clients see a dual stack network. And no NAT64 does not imply DNS64. You can publish a ipv4only.arpa zone with the mappings for the NAT64. There are now also RA options for publishing these mappings. There are also DHCPv6 options. Mark > Bjørn -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Ipv6 help
On 27/Aug/20 07:58, Bjørn Mork wrote: > Because NAT64 implies DNS64, which avoids NATing any dual stack service. > This makes a major difference today. NAT64/DNS64 was the original solution. 464XLAT is the improved approach. See: https://tools.ietf.org/id/draft-ietf-v6ops-nat64-deployment-04.html Mark.
Re: Ipv6 help
On 26/Aug/20 22:23, JORDI PALET MARTINEZ via NANOG wrote: > Maybe the only way to force this is to tell our customers (many ISPs in every > country) "don't buy Sony PS, they are unable to support new technologies, so > you games will be blocked by Sony". Of course, unless we all decide to use > 464XLAT instead of CGN ... which resolves the problem. Somehow, I don't see this happening. Most ISP's probably know a little bit about gaming because the engineers have a console at home, or in the NOC. To get them to a level where they are actively asking customers not to buy games developed for Sony, at scale, is probably an entire project on its own that a basic ISP can't justify time for. Also, it's unlikely that end-users are going to listen to advice not to buy Sony games. All they'll hear is, "My ISP doesn't know how to fix this, so I must find another one that does". We need a better plan. As with everything in life, it probably comes down to a "Vijay Gill moving ATDN to IS-IS" type-thing, i.e., an actual person that understands what to do, cares about IPv6, and has influence within Sony. Mark.
Re: Ipv6 help
Brian Johnson writes: >> 1) It needs *much less* IPv4 addresses (in the NAT64) for the same number of >> customers. > > I cannot see how this is even possible. If I use private space > internally to the CGN, then the available external space is the same > and the internal customers are the same and I can do the same over sub > ratio under both circumstance. Tell me how the math is different. Because NAT64 implies DNS64, which avoids NATing any dual stack service. This makes a major difference today. Bjørn
Re: Ipv6 help
On 26/Aug/20 22:12, JORDI PALET MARTINEZ wrote: > And the PS developers missed by themselves all about IPv6. Furthermore, I > still see some game makers *encouraging customers* to disable IPv6. I call > this a *criminal action*. Most developers do not understand the constraints the industry is facing re: IPv4, or know that there are constraints but figure, "Ah, those network engineers will make a plan, don't worry about it, and don't care about IPv6". Mark.
Re: Ipv6 help
I do not work at either NANOG or Sony. How would my response imply that? Again, what is your point? I have attended a lot of NANOG meetings and CGM/IPv6 transition was a point of discussion many times, but as usual it was always in the ether. Few actually deployed examples and always worried about breaking the Internet. We broke it decades ago and now we are reaping the rewards. > On Aug 26, 2020, at 4:22 PM, surfer wrote: > > On 8/26/20 9:28 AM, Tony Wicks wrote: They're the worst service company I have ever had the displeasure of dealing with, the arrogance and attitude of we are big, you are small we don't care about your customers was infuriating. Never have I seen a single call related to their opposition where as PSN accounted for about 10-20% of helpdesk calls. I don't understand why its seemingly impossible for them to implement ipv6 as almost everything I have deployed with CGN is dual stack V6. >>> On 8/26/20 9:30 AM, Mark Tinka wrote: We'll have to be creative with how we pressure them into getting serious about IPv6. >>> On Aug 26, 2020, at 3:06 PM, surfer wrote: >>> >>> Do those guys attend NANOG meetings? >;-) (evil smile) > > On 8/26/20 10:09 AM, Brian Johnson wrote: >> I have/do. Do you have a point? > --- > > > I guess you're implying you work there. Maybe someone will bake a cake for > your company. > > scott > > >
Re: Ipv6 help
Responses in-line > On Aug 26, 2020, at 4:07 PM, JORDI PALET MARTINEZ via NANOG > wrote: > > Because: > > 1) It needs *much less* IPv4 addresses (in the NAT64) for the same number of > customers. I cannot see how this is even possible. If I use private space internally to the CGN, then the available external space is the same and the internal customers are the same and I can do the same over sub ratio under both circumstance. Tell me how the math is different. > 2) It provides the customers as many ports they need (no a limited number of > ports per customer). See response to answer 1 > 3) It is not blocked by PSN (don't know why because don't know how the games > have problems with CGN). Interesting, but I’m not sure how any over-loaded NAT translation would look different from the external system. Since you cannot explain it, it’s hard to discuss it. > > You could share among an *almost unlimited* number of subscribers an small > IPv4 block (even just a /22). The math would be the same as a CGN, so I do not see how this is any less or more useful. It does, however, require CPE capability that appears lacking and NAT444 does not. > > Regards, > Jordi > @jordipalet > > > > El 26/8/20 22:31, "Brian Johnson" escribió: > >How does 464XLAT solve the problem if you are out of IPv4 space? > >> On Aug 26, 2020, at 3:23 PM, JORDI PALET MARTINEZ via NANOG >> wrote: >> >> They know we are there ... so they don't come! >> >> By the way I missed this in the previous email: I heard (not sure how much >> true on that) that they are "forced" to avoid CGN because the way games are >> often programmed in PSP break them. So maybe will not be enough to sort out >> the problem with an OS and/or PSN change, all the affected games, will need >> to be adjusted. >> >> Maybe the only way to force this is to tell our customers (many ISPs in >> every country) "don't buy Sony PS, they are unable to support new >> technologies, so you games will be blocked by Sony". Of course, unless we >> all decide to use 464XLAT instead of CGN ... which resolves the problem. >> >> A massive campaing could work ... >> >> >> El 26/8/20 22:08, "NANOG en nombre de surfer" >> > sur...@mauigateway.com> escribió: >> >> >> >> On 8/26/20 9:28 AM, Tony Wicks wrote: >>> They're the worst service company I have ever had the displeasure of >>> dealing with, the arrogance and attitude of we are big, you are small we >>> don't care about your customers was infuriating. Never have I seen a single >>> call related to their opposition where as PSN accounted for about 10-20% of >>> helpdesk calls. I don't understand why its seemingly impossible for them to >>> implement ipv6 as almost everything I have deployed with CGN is dual stack >>> V6. >> >> On 8/26/20 9:30 AM, Mark Tinka wrote: >>> We'll have to be creative with how we pressure them into getting serious >>> about IPv6. >> >> >> Do those guys attend NANOG meetings? >;-) (evil smile) >> >> scott >> >> >> >> ** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.theipv6company.com >> The IPv6 Company >> >> This electronic message contains information which may be privileged or >> confidential. The information is intended to be for the exclusive use of the >> individual(s) named above and further non-explicilty authorized disclosure, >> copying, distribution or use of the contents of this information, even if >> partially, including attached files, is strictly prohibited and will be >> considered a criminal offense. If you are not the intended recipient be >> aware that any disclosure, copying, distribution or use of the contents of >> this information, even if partially, including attached files, is strictly >> prohibited, will be considered a criminal offense, so you must reply to the >> original sender to inform about this communication and delete it. >> >> >> > > > > > ** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of the > individual(s) named above and further non-explicilty authorized disclosure, > copying, distribution or use of the contents of this information, even if > partially, including attached files, is strictly prohibited and will be > considered a criminal offense. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited, will be considered a criminal offense, so you must reply to the > original sender to inform about this communication and delete it. > > >
Re: Ipv6 help
On Wed, 26 Aug 2020 18:42:14 +0200, JORDI PALET MARTINEZ via NANOG said: > The crazy thing is that PSN doesn't (up to my knowledge) yet work with IPv6 . Has anybody heard if they plan to fix that with the imminent Playstation 5? The PS4 OS will actually talk IPV6 far enough to DHCPv6 and answer pings from both on and off subnet, but none of the userspace does it because that API wasn't in the developer's kits at launch. pgp4TBzYh_Kka.pgp Description: PGP signature
Re: TCP and UDP Port 0 - Should an ISP or ITP Block it?
Nick, Data on blocking inbound TCP or the kinds of gear that mistakenly labels UDP fragments as DST port 0? Scott Helms On Wed, Aug 26, 2020 at 9:00 AM Nick Hilliard wrote: > > K. Scott Helms wrote on 26/08/2020 13:55: > > To be clear, UDP port 0 is not and probably shouldn't be blocked > > because some network gear and reporting tools may mistake a fragmented > > UDP PDU for port 0. That's an implementation error, but one that may > > be common enough to create issues for users. > do you have data on this? > > Nick >
Re: Ipv6 help
On 8/26/20 9:28 AM, Tony Wicks wrote: They're the worst service company I have ever had the displeasure of dealing with, the arrogance and attitude of we are big, you are small we don't care about your customers was infuriating. Never have I seen a single call related to their opposition where as PSN accounted for about 10-20% of helpdesk calls. I don't understand why its seemingly impossible for them to implement ipv6 as almost everything I have deployed with CGN is dual stack V6. On 8/26/20 9:30 AM, Mark Tinka wrote: We'll have to be creative with how we pressure them into getting serious about IPv6. On Aug 26, 2020, at 3:06 PM, surfer wrote: Do those guys attend NANOG meetings? >;-) (evil smile) On 8/26/20 10:09 AM, Brian Johnson wrote: I have/do. Do you have a point? --- I guess you're implying you work there. Maybe someone will bake a cake for your company. scott
Re: Ipv6 help
Because: 1) It needs *much less* IPv4 addresses (in the NAT64) for the same number of customers. 2) It provides the customers as many ports they need (no a limited number of ports per customer). 3) It is not blocked by PSN (don't know why because don't know how the games have problems with CGN). You could share among an *almost unlimited* number of subscribers an small IPv4 block (even just a /22). Regards, Jordi @jordipalet El 26/8/20 22:31, "Brian Johnson" escribió: How does 464XLAT solve the problem if you are out of IPv4 space? > On Aug 26, 2020, at 3:23 PM, JORDI PALET MARTINEZ via NANOG wrote: > > They know we are there ... so they don't come! > > By the way I missed this in the previous email: I heard (not sure how much true on that) that they are "forced" to avoid CGN because the way games are often programmed in PSP break them. So maybe will not be enough to sort out the problem with an OS and/or PSN change, all the affected games, will need to be adjusted. > > Maybe the only way to force this is to tell our customers (many ISPs in every country) "don't buy Sony PS, they are unable to support new technologies, so you games will be blocked by Sony". Of course, unless we all decide to use 464XLAT instead of CGN ... which resolves the problem. > > A massive campaing could work ... > > > El 26/8/20 22:08, "NANOG en nombre de surfer" escribió: > > > >On 8/26/20 9:28 AM, Tony Wicks wrote: >> They're the worst service company I have ever had the displeasure of dealing with, the arrogance and attitude of we are big, you are small we don't care about your customers was infuriating. Never have I seen a single call related to their opposition where as PSN accounted for about 10-20% of helpdesk calls. I don't understand why its seemingly impossible for them to implement ipv6 as almost everything I have deployed with CGN is dual stack V6. > >On 8/26/20 9:30 AM, Mark Tinka wrote: >> We'll have to be creative with how we pressure them into getting serious >> about IPv6. > > >Do those guys attend NANOG meetings? >;-) (evil smile) > >scott > > > > ** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > ** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
Re: Ipv6 help
How does 464XLAT solve the problem if you are out of IPv4 space? > On Aug 26, 2020, at 3:23 PM, JORDI PALET MARTINEZ via NANOG > wrote: > > They know we are there ... so they don't come! > > By the way I missed this in the previous email: I heard (not sure how much > true on that) that they are "forced" to avoid CGN because the way games are > often programmed in PSP break them. So maybe will not be enough to sort out > the problem with an OS and/or PSN change, all the affected games, will need > to be adjusted. > > Maybe the only way to force this is to tell our customers (many ISPs in every > country) "don't buy Sony PS, they are unable to support new technologies, so > you games will be blocked by Sony". Of course, unless we all decide to use > 464XLAT instead of CGN ... which resolves the problem. > > A massive campaing could work ... > > > El 26/8/20 22:08, "NANOG en nombre de surfer" > sur...@mauigateway.com> escribió: > > > >On 8/26/20 9:28 AM, Tony Wicks wrote: >> They're the worst service company I have ever had the displeasure of dealing >> with, the arrogance and attitude of we are big, you are small we don't care >> about your customers was infuriating. Never have I seen a single call >> related to their opposition where as PSN accounted for about 10-20% of >> helpdesk calls. I don't understand why its seemingly impossible for them to >> implement ipv6 as almost everything I have deployed with CGN is dual stack >> V6. > >On 8/26/20 9:30 AM, Mark Tinka wrote: >> We'll have to be creative with how we pressure them into getting serious >> about IPv6. > > >Do those guys attend NANOG meetings? >;-) (evil smile) > >scott > > > > ** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of the > individual(s) named above and further non-explicilty authorized disclosure, > copying, distribution or use of the contents of this information, even if > partially, including attached files, is strictly prohibited and will be > considered a criminal offense. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited, will be considered a criminal offense, so you must reply to the > original sender to inform about this communication and delete it. > > >
Re: Ipv6 help
They know we are there ... so they don't come! By the way I missed this in the previous email: I heard (not sure how much true on that) that they are "forced" to avoid CGN because the way games are often programmed in PSP break them. So maybe will not be enough to sort out the problem with an OS and/or PSN change, all the affected games, will need to be adjusted. Maybe the only way to force this is to tell our customers (many ISPs in every country) "don't buy Sony PS, they are unable to support new technologies, so you games will be blocked by Sony". Of course, unless we all decide to use 464XLAT instead of CGN ... which resolves the problem. A massive campaing could work ... El 26/8/20 22:08, "NANOG en nombre de surfer" escribió: On 8/26/20 9:28 AM, Tony Wicks wrote: > They're the worst service company I have ever had the displeasure of dealing with, the arrogance and attitude of we are big, you are small we don't care about your customers was infuriating. Never have I seen a single call related to their opposition where as PSN accounted for about 10-20% of helpdesk calls. I don't understand why its seemingly impossible for them to implement ipv6 as almost everything I have deployed with CGN is dual stack V6. On 8/26/20 9:30 AM, Mark Tinka wrote: > We'll have to be creative with how we pressure them into getting serious > about IPv6. Do those guys attend NANOG meetings? >;-) (evil smile) scott ** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
Re: Ipv6 help
I believe Sony missed: 1) Telling the developers to make sure that they program with IPv6 in mind (MS/XBOX did for years). 2) Fully supporting IPv6 in the PSN and the PlayStation OS (MS/XBOS did). 3) Setting a deadline for developers to start using it (MS/XBOX did, Apple - different business I know - did for IPv6-only in iOS) And the PS developers missed by themselves all about IPv6. Furthermore, I still see some game makers *encouraging customers* to disable IPv6. I call this a *criminal action*. Sony has IPv6 in other products, but of course, it is a big company, many times it happens they are "disconnected" folks there. El 26/8/20 20:16, "NANOG en nombre de Brian Johnson" escribió: 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. > On Aug 26, 2020, at 1:09 PM, Mark Tinka wrote: > > > > On 26/Aug/20 18:42, JORDI PALET MARTINEZ via NANOG wrote: > >> The crazy thing is that PSN doesn't (up to my knowledge) yet work with IPv6 ... > > 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. ** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
Re: Ipv6 help
I have/do. Do you have a point? > On Aug 26, 2020, at 3:06 PM, surfer wrote: > > > > On 8/26/20 9:28 AM, Tony Wicks wrote: >> They're the worst service company I have ever had the displeasure of dealing >> with, the arrogance and attitude of we are big, you are small we don't care >> about your customers was infuriating. Never have I seen a single call >> related to their opposition where as PSN accounted for about 10-20% of >> helpdesk calls. I don't understand why its seemingly impossible for them to >> implement ipv6 as almost everything I have deployed with CGN is dual stack >> V6. > > On 8/26/20 9:30 AM, Mark Tinka wrote: >> We'll have to be creative with how we pressure them into getting serious >> about IPv6. > > > Do those guys attend NANOG meetings? >;-) (evil smile) > > scott
Re: Ipv6 help
On 8/26/20 9:28 AM, Tony Wicks wrote: They're the worst service company I have ever had the displeasure of dealing with, the arrogance and attitude of we are big, you are small we don't care about your customers was infuriating. Never have I seen a single call related to their opposition where as PSN accounted for about 10-20% of helpdesk calls. I don't understand why its seemingly impossible for them to implement ipv6 as almost everything I have deployed with CGN is dual stack V6. On 8/26/20 9:30 AM, Mark Tinka wrote: We'll have to be creative with how we pressure them into getting serious about IPv6. Do those guys attend NANOG meetings? >;-) (evil smile) scott
Re: Ipv6 help
Mark: We are completely in agreement. Great dialog here. > On Aug 26, 2020, at 2:30 PM, Mark Tinka wrote: > > > > On 26/Aug/20 21:14, Brian Johnson wrote: > >> I can prove, as an ISP, that I am delivering the packets. Many providers >> will have to do this until the content moves to IPv6, so what will their >> excuse be? The provider has no choice when they have more customers than >> IPv4 address space. They will have to do something to provide access to the >> IPv4 Internet for these customers. If the ISP created a service that wasn’t >> NAT444 for gamers and charged accordingly, they would probably get drawn and >> quartered. >> >> It’s a no win situation and it really is Sony that is causing this issue. PR >> campaigns and educating customers is probably the only way they can win this >> argument, when they already have the technical battle won. > > In essence, yes. > > But most gaming customers don't have the time to decipher .pcap files > proving that you delivered the traffic to Sony. > > And Sony are counting on this. > > We'll have to be creative with how we pressure them into getting serious > about IPv6. > > Mark.
Re: Ipv6 help
On 26/Aug/20 21:14, Brian Johnson wrote: > I can prove, as an ISP, that I am delivering the packets. Many providers will > have to do this until the content moves to IPv6, so what will their excuse > be? The provider has no choice when they have more customers than IPv4 > address space. They will have to do something to provide access to the IPv4 > Internet for these customers. If the ISP created a service that wasn’t NAT444 > for gamers and charged accordingly, they would probably get drawn and > quartered. > > It’s a no win situation and it really is Sony that is causing this issue. PR > campaigns and educating customers is probably the only way they can win this > argument, when they already have the technical battle won. In essence, yes. But most gaming customers don't have the time to decipher .pcap files proving that you delivered the traffic to Sony. And Sony are counting on this. We'll have to be creative with how we pressure them into getting serious about IPv6. Mark.
RE: Ipv6 help
This is nothing new, when I first started installing CGN platforms something like 10 years ago there was only ever one company that caused issues, can you guess which? It got to the point of lawyers exchanging desist letters as PSN constantly told our customers that they were blocking to contact us as somehow the ISP has control over what Sony blocks on PSN. They're the worst service company I have ever had the displeasure of dealing with, the arrogance and attitude of we are big, you are small we don't care about your customers was infuriating. Never have I seen a single call related to their opposition where as PSN accounted for about 10-20% of helpdesk calls. I don't understand why its seemingly impossible for them to implement ipv6 as almost everything I have deployed with CGN is dual stack V6. -Original Message- From: NANOG On Behalf Of Brian Johnson Sent: Thursday, 27 August 2020 7:14 am To: Mark Tinka Cc: nanog@nanog.org Subject: Re: Ipv6 help I can prove, as an ISP, that I am delivering the packets. Many providers will have to do this until the content moves to IPv6, so what will their excuse be? The provider has no choice when they have more customers than IPv4 address space. They will have to do something to provide access to the IPv4 Internet for these customers. If the ISP created a service that wasn’t NAT444 for gamers and charged accordingly, they would probably get drawn and quartered. It’s a no win situation and it really is Sony that is causing this issue. PR campaigns and educating customers is probably the only way they can win this argument, when they already have the technical battle won. Just checked with 2 of my customers who do NAT444 and no issues with PSN… YMMV. > On Aug 26, 2020, at 2:00 PM, Mark Tinka wrote: > > > > On 26/Aug/20 20:38, Brian Johnson wrote: > >> I‘m going further... They shouldn’t have to care. Sony should understand >> what they are delivering and the circumstance of that. That they refuse to >> serve some customers due to the technology they use is either a business >> decision or a faulty design. The end-customer (gamer) doesn’t care. They >> just want to play. > > Sony know that when connectivity breaks because they marked a > NAT444'ed IP address as a DDoS source, the end-user won't complain to > Sony (that's a customer service blackhole). The end-user will complain to the > ISP. > > Chain of responsibility is in the ISP's disfavour. Sony don't have to > do anything. It's like sending an e-mail to an abuse@ mail box. You > sort of know it won't get answered, and are powerless if it isn't answered. > > Mark.
Re: Ipv6 help
I can prove, as an ISP, that I am delivering the packets. Many providers will have to do this until the content moves to IPv6, so what will their excuse be? The provider has no choice when they have more customers than IPv4 address space. They will have to do something to provide access to the IPv4 Internet for these customers. If the ISP created a service that wasn’t NAT444 for gamers and charged accordingly, they would probably get drawn and quartered. It’s a no win situation and it really is Sony that is causing this issue. PR campaigns and educating customers is probably the only way they can win this argument, when they already have the technical battle won. Just checked with 2 of my customers who do NAT444 and no issues with PSN… YMMV. > On Aug 26, 2020, at 2:00 PM, Mark Tinka wrote: > > > > On 26/Aug/20 20:38, Brian Johnson wrote: > >> I‘m going further... They shouldn’t have to care. Sony should understand >> what they are delivering and the circumstance of that. That they refuse to >> serve some customers due to the technology they use is either a business >> decision or a faulty design. The end-customer (gamer) doesn’t care. They >> just want to play. > > Sony know that when connectivity breaks because they marked a NAT444'ed > IP address as a DDoS source, the end-user won't complain to Sony (that's > a customer service blackhole). The end-user will complain to the ISP. > > Chain of responsibility is in the ISP's disfavour. Sony don't have to do > anything. It's like sending an e-mail to an abuse@ mail box. You sort of > know it won't get answered, and are powerless if it isn't answered. > > Mark.
Re: Ipv6 help
And in the end it will come down to a clueful customer taking Sony to task. with the backing of a government for selling a product which is not fit for purpose. They have paid to play games and if Sony is blocking them because they happen to be on a CGN, which they have no control over, then Sony is in breach of lots of consumer laws around the planet. No EULA trumps the law. Here is Australia it would be the ACCC that would take them to task. -- Mark Andrews > On 27 Aug 2020, at 04:38, Brian Johnson wrote: > > I‘m going further... They shouldn’t have to care. Sony should understand > what they are delivering and the circumstance of that. That they refuse to > serve some customers due to the technology they use is either a business > decision or a faulty design. The end-customer (gamer) doesn’t care. They just > want to play. > > >> On Aug 26, 2020, at 1:31 PM, Mark Tinka wrote: >> >> >> >>> On 26/Aug/20 20:20, Brian Johnson wrote: >>> >>> Either way. Nothing you can do in the network will help Sony enable IPv6 >>> capability, Or to serve their users even if using a technology that they do >>> not like. >> >> Agreed. >> >> The problem is gaming customers that neither care for nor know about how >> NAT444 and/or IPv6 play (no pun intended) here. >> >> Mark. >
Re: Ipv6 help
On 26/Aug/20 20:38, Brian Johnson wrote: > I‘m going further... They shouldn’t have to care. Sony should understand what > they are delivering and the circumstance of that. That they refuse to serve > some customers due to the technology they use is either a business decision > or a faulty design. The end-customer (gamer) doesn’t care. They just want to > play. Sony know that when connectivity breaks because they marked a NAT444'ed IP address as a DDoS source, the end-user won't complain to Sony (that's a customer service blackhole). The end-user will complain to the ISP. Chain of responsibility is in the ISP's disfavour. Sony don't have to do anything. It's like sending an e-mail to an abuse@ mail box. You sort of know it won't get answered, and are powerless if it isn't answered. Mark.
Re: Ipv6 help
I‘m going further... They shouldn’t have to care. Sony should understand what they are delivering and the circumstance of that. That they refuse to serve some customers due to the technology they use is either a business decision or a faulty design. The end-customer (gamer) doesn’t care. They just want to play. > On Aug 26, 2020, at 1:31 PM, Mark Tinka wrote: > > > > On 26/Aug/20 20:20, Brian Johnson wrote: > >> Either way. Nothing you can do in the network will help Sony enable IPv6 >> capability, Or to serve their users even if using a technology that they do >> not like. > > Agreed. > > The problem is gaming customers that neither care for nor know about how > NAT444 and/or IPv6 play (no pun intended) here. > > Mark.
Re: Ipv6 help
On 26/Aug/20 20:20, Brian Johnson wrote: > Either way. Nothing you can do in the network will help Sony enable IPv6 > capability, Or to serve their users even if using a technology that they do > not like. Agreed. The problem is gaming customers that neither care for nor know about how NAT444 and/or IPv6 play (no pun intended) here. Mark.
Re: Ipv6 help
Either way. Nothing you can do in the network will help Sony enable IPv6 capability, Or to serve their users even if using a technology that they do not like. > On Aug 26, 2020, at 1:17 PM, Mark Tinka wrote: > > > > On 26/Aug/20 20:14, Brian Johnson wrote: > >> 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.
Re: Ipv6 help
On 26/Aug/20 18:48, JORDI PALET MARTINEZ via NANOG wrote: > 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. 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.
Re: Ipv6 help
On 26/Aug/20 20:14, Brian Johnson wrote: > 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.
Re: Ipv6 help
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. > On Aug 26, 2020, at 1:09 PM, Mark Tinka wrote: > > > > On 26/Aug/20 18:42, JORDI PALET MARTINEZ via NANOG wrote: > >> The crazy thing is that PSN doesn't (up to my knowledge) yet work with IPv6 >> ... > > 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.
Re: Ipv6 help
On 26/Aug/20 18:42, JORDI PALET MARTINEZ via NANOG wrote: > The crazy thing is that PSN doesn't (up to my knowledge) yet work with IPv6 > ... 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.
Re: Ipv6 help
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" escribió: On 8/26/20 2:48 AM, JORDI PALET MARTINEZ via NANOG wrote: > 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. -- Brandon Martin ** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
Re: Ipv6 help
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" 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. > On Aug 26, 2020, at 2:13 AM, JORDI PALET MARTINEZ via NANOG wrote: > > 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" 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 > >> On 26 Aug 2020, at 16:51, JORDI PALET MARTINEZ via NANOG wrote: >> >> 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" 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. >> >> >>> On Aug 25, 2020, at 3:15 PM, Brandon Martin wrote: >>> >>> On 8/25/20 3:38 PM, JORDI PALET MARTINEZ via NANOG wrote: 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... >>> -- >>> Brandon Martin >> >> >> >> >> ** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.theipv6company.com >> The IPv6 Company >> >> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >> >>
Re: Ipv6 help
On 8/26/20 2:48 AM, JORDI PALET MARTINEZ via NANOG wrote: 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. -- Brandon Martin
Re: Ipv6 help
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
Re: Ipv6 help
On 26/Aug/20 16:38, Brian Johnson wrote: > 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'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.
Re: Ipv6 help
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. > On Aug 26, 2020, at 2:13 AM, JORDI PALET MARTINEZ via NANOG > wrote: > > 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" 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 > >> On 26 Aug 2020, at 16:51, JORDI PALET MARTINEZ via NANOG >> wrote: >> >> 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" >> > brian.john...@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. >> >> >>> On Aug 25, 2020, at 3:15 PM, Brandon Martin >>> wrote: >>> >>> On 8/25/20 3:38 PM, JORDI PALET MARTINEZ via NANOG wrote: 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... >>> -- >>> Brandon Martin >> >> >> >> >> ** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.theipv6company.com >> The IPv6 Company >> >> This electronic message contains information which may be privileged or >> confidential. The information is intended to be for the exclusive use of the >> individual(s) named above and further non-explicilty authorized disclosure, >> copying, distribution or use of the contents of this information, even if >> partially, including attached files, is strictly prohibited and will be >> considered a criminal offense. If you are not the intended recipient be >> aware that any disclosure, copying, distribution or use of the contents of >> this information, even if partially, including attached files, is strictly >> prohibited, will be considered a criminal offense, so you must reply to the >> original sender to inform about this communication and delete it. >> >> >> > >-- >Mark Andrews, ISC >1 Seymour St., Dundas Valley, NSW 2117, Australia >PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > > > > ** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of the > individual(s) named above and further non-explicilty authorized disclosure, > copying, distribution or use of the contents of this information, even if > partially, incl
Re: Ipv6 help
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. > On Aug 25, 2020, at 11:46 PM, Mark Tinka wrote: > > > > On 25/Aug/20 22:40, Brian Johnson wrote: > >> 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. > > 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.
Re: TCP and UDP Port 0 - Should an ISP or ITP Block it?
K. Scott Helms wrote on 26/08/2020 13:55: To be clear, UDP port 0 is not and probably shouldn't be blocked because some network gear and reporting tools may mistake a fragmented UDP PDU for port 0. That's an implementation error, but one that may be common enough to create issues for users. do you have data on this? Nick
Re: TCP and UDP Port 0 - Should an ISP or ITP Block it?
To be clear, UDP port 0 is not and probably shouldn't be blocked because some network gear and reporting tools may mistake a fragmented UDP PDU for port 0. That's an implementation error, but one that may be common enough to create issues for users. Blocking inbound TCP port 0 is something that I've personally done in dozens of ISP networks over more than a decade without a single reported issue. Scott Helms On Tue, Aug 25, 2020 at 7:39 PM narhiro wrote: > > > > "Port 0 is a reserved port, which means it should not be used by > > applications. Network abuse has prompted the need to block this port." > > > > "What about UDP IP fragmentation?" > > > > I'm not sure I follow this. The IP packet will be fragmented with UDP > > inside it. When the IP packet gets put together the UDP PDU will have > > a port number. It's possible that some packet analyzers or network > > gear will improperly "see" a partial UDP flow as port 0 but that's a > > mischaracterization of the flow. > > > > > > Scott Helms > > > > Scott Helms > > > > > > > >>> On Tue, Aug 25, 2020 at 8:17 AM Job Snijders wrote: > >>> > On Tue, Aug 25, 2020 at 07:27:33AM -0400, K. Scott Helms wrote: > >>> I think a fairly easy thing to do is see what other large retail ISPs > >>> have done. Comcast, as an example, lists all of the ports they block > >>> and 0 is blocked. I do recommend that port 0 be blocked by all of the > >>> ISPs I work with and frankly Comcast's list is a pretty good one to > >>> use in general, though you will get some pushback on things like SMTP. > >>> https://www.xfinity.com/support/articles/list-of-blocked-ports > >> > >> I may be reading the table incorrectly, but it seems to me Comcast is > >> *not* blocking UDP port 0 according to the above URL? > >> > >>> Transit providers are a little bit different, but then again port 0 is > >>> also different since AFAIK it's never had a legitimate use case. It's > >>> always been a reserved port. I'd personally block it if I ran a > >>> transit, but I'd be more willing to open it up for one of my large > >>> customers (in a limited way) than I would on the retail side. > >>> https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml > >> > >> What about UDP IP fragmentation? > >> > >> Kind regards, > >> > >> Job
Re: Ipv6 help
On 26/Aug/20 10:49, 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. 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.
Re: RPKI chain of trust
Hi Fabiano, > On 26 Aug 2020, at 11:03, Fabiano D'Agostino > wrote: > > Hi Alex, > thank you. I read that documentation and I was reading this one from page 201: > https://www.ripe.net/support/training/material/bgp-operations-and-security-training-course/BGP-Slides-Single.pdf > > > It seems that RIRs have a self-signed root certificate. They use this > certificate to sign LIR's certificates and LIR's private key is used to sign > ROAs. I am not very sure about the use of public keys. The “LIR”’s public key is on the certificate signed by the RIR and that makes the chain. -Alex
Re: RPKI chain of trust
Hi Alex, thank you. I read that documentation and I was reading this one from page 201: https://www.ripe.net/support/training/material/bgp-operations-and-security-training-course/BGP-Slides-Single.pdf It seems that RIRs have a self-signed root certificate. They use this certificate to sign LIR's certificates and LIR's private key is used to sign ROAs. I am not very sure about the use of public keys. Fabiano Il giorno mer 26 ago 2020 alle ore 10:39 Alex Band ha scritto: > Perhaps this clarifies things: > > > https://rpki.readthedocs.io/en/latest/rpki/introduction.html#mapping-the-resource-allocation-hierarchy-into-the-rpki > > As well as this section: > > https://rpki.readthedocs.io/en/latest/rpki/securing-bgp.html > > Cheers, > > Alex > > > On 26 Aug 2020, at 10:25, Fabiano D'Agostino < > fabiano.dagostin...@gmail.com> wrote: > > > > Good morning everyone, > > I have a doubt about RPKI chain of trust. The 5 RIRs hold a self-signed > root certificate for all the resources they have in the registry. The root > certificate is used to sign the LIR's certificates that lists LIR's > resources. LIRs use their private key to sign ROAs. LIR's public key is > used to verify ROAs signatures and RIRs public key is used to verify LIR's > signatures. > > > > Is this correct? > > > > Thanks in advance, > > > > Fabiano > >
Re: TCP and UDP Port 0 - Should an ISP or ITP Block it?
What problem are you trying to solve? Bjørn
Re: Ipv6 help
Brandon Martin writes: > On 8/25/20 3:38 PM, JORDI PALET MARTINEZ via NANOG wrote: >> 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
Re: RPKI chain of trust
Perhaps this clarifies things: https://rpki.readthedocs.io/en/latest/rpki/introduction.html#mapping-the-resource-allocation-hierarchy-into-the-rpki As well as this section: https://rpki.readthedocs.io/en/latest/rpki/securing-bgp.html Cheers, Alex > On 26 Aug 2020, at 10:25, Fabiano D'Agostino > wrote: > > Good morning everyone, > I have a doubt about RPKI chain of trust. The 5 RIRs hold a self-signed root > certificate for all the resources they have in the registry. The root > certificate is used to sign the LIR's certificates that lists LIR's > resources. LIRs use their private key to sign ROAs. LIR's public key is used > to verify ROAs signatures and RIRs public key is used to verify LIR's > signatures. > > Is this correct? > > Thanks in advance, > > Fabiano
RPKI chain of trust
Good morning everyone, I have a doubt about RPKI chain of trust. The 5 RIRs hold a self-signed root certificate for all the resources they have in the registry. The root certificate is used to sign the LIR's certificates that lists LIR's resources. LIRs use their private key to sign ROAs. LIR's public key is used to verify ROAs signatures and RIRs public key is used to verify LIR's signatures. Is this correct? Thanks in advance, Fabiano
Re: Ipv6 help
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" 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 > On 26 Aug 2020, at 16:51, JORDI PALET MARTINEZ via NANOG wrote: > > 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" 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. > > >> On Aug 25, 2020, at 3:15 PM, Brandon Martin wrote: >> >> On 8/25/20 3:38 PM, JORDI PALET MARTINEZ via NANOG wrote: >>> 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... >> -- >> Brandon Martin > > > > > ** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
Re: Ipv6 help
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 > On 26 Aug 2020, at 16:51, JORDI PALET MARTINEZ via NANOG > wrote: > > 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" > brian.john...@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. > > >> On Aug 25, 2020, at 3:15 PM, Brandon Martin wrote: >> >> On 8/25/20 3:38 PM, JORDI PALET MARTINEZ via NANOG wrote: >>> 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... >> -- >> Brandon Martin > > > > > ** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of the > individual(s) named above and further non-explicilty authorized disclosure, > copying, distribution or use of the contents of this information, even if > partially, including attached files, is strictly prohibited and will be > considered a criminal offense. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited, will be considered a criminal offense, so you must reply to the > original sender to inform about this communication and delete it. > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
