Re: DualStack (CGNAT) vs Other Transition methods

[Douglas Fischer]

Em ter., 6 de abr. de 2021 às 04:32, JORDI PALET MARTINEZ via NANOG <
nanog@nanog.org> escreveu:
>
>
> I don’t understand what you mean with the support folks, they just do
what their boss decides, like in any other technology deployment.


Well, Jordi... Do You know what is the important Body Part?
https://www.reddit.com/r/Jokes/comments/2vgpzs/the_most_important_body_part/
😂😅

To me(and all that I know in ISP industries, including the very small and
the big ones) according to what is explained on the link above, if the ISP
would be a human body, the support would be equivalent to the rectum.

Re: DualStack (CGNAT) vs Other Transition methods

[JORDI PALET MARTINEZ via NANOG]

In the pilot we have got, up to now, *0* support tickets related to 464XLAT, 
just normal ones.

 

I think Cameron already told, if I’m not confused, they didn’t get support 
tickets, and they are doing 464XLAT in cellular and broadband for many years 
with hundreds of millions of customers.

 

I don’t understand what you mean with the support folks, they just do what 
their boss decides, like in any other technology deployment.

 

Of course I agree that Sony PS is not doing well, but they have been doing so 
bad for ages already (compared with Microsoft, Google, etc., etc.), 
unfortunately they don’t go to events or respond to emails to help them. If 
someone has a better contact, will be happy to help!

 

Regards,

Jordi

@jordipalet

 

 

 

El 6/4/21 0:18, "NANOG en nombre de Douglas Fischer" 
 escribió:

 

Jordi, If I sum the numbers of times "It is a deployment with 25.000.000 
customers, using GPON, DSL and cellular." (or similar)(EN, ES, PT) appears on 
my mail box, I guess will be over 2 hundred...

But every time it hits on:
 -> Support Tickets! What do they tell us?
 -> Field Support and L1 Support Guys. Do they agree with that?

Let me be clear:
- I like IPv6!
- I encourage the use of IPv6!
- I think those guys that say "IPv6 won't be adopted" a bunch of lunatics!

But, more important than IPv4, IPv6, "IPv12" is that my customers become happy 
and D'ONT BOTHER ME.
If I would use IPX/SPX and get them even happier than they are today, I would 
do!

The important message on Tore's post IS NOT "464XLAT is better then Dual Stack".
The important message on Tore's post IS NOT "Sony and Playstation are doing 
IPv6 in the wrong way!".  

Could you please help every ISP, Every Gamer, demanding Sony and Playstation to 
do IPv6 the right way, without wanting to "seize the occasion" to publicize the 
IPv6 transition case and consultancy service?
 Please?  


 

Em seg., 5 de abr. de 2021 às 17:02, JORDI PALET MARTINEZ via NANOG 
 escreveu:

Hi Douglas,

 

In a different mailing list, we had a discussion with Tore about his testing 
and other testing that may not be available in that blog. It was basically 
about 464XLAT.

 

As you know IPv6-only with IPv4aaS, provides *dual-stack* in the customer LANs, 
where the PS5 was sitting.

 

So, we concluded in that discussion that there is *no difference* for the PS5 
being used with 464XLAT vs “regular dual-stack”, as expected.

 

Further to that, I’ve done a very complete testing, for a customer, with a PS4 
in a LAN with 464XLAT and everything worked fine. Unfortunately, as this was 
contracted by a customer, I can’t disclose all the test set, but believe me it 
worked. It is a deployment with 25.000.000 customers, using GPON, DSL and 
cellular.

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 5/4/21 21:32, "NANOG en nombre de Douglas Fischer" 
 escribió:

 

Here goes a link fo an excellent analysis of IPv6 and Playstation

This says a lot about why some prefer DualStack.

https://toreanderson.github.io/2021/02/23/ipv6-support-in-the-playstation-5.html

 

Em ter., 2 de mar. de 2021 às 07:59, Douglas Fischer  
escreveu:

Hello Mark...

Yes, until when I was decided to Fight Agins IPv4, I tried the Fixes.

But after some time, I saw that very little of the problems were due to 
inadequacies of the ISP's responsibility equipment.


Most of the difficulties stemmed from:
A) Choices of end-users in their networks.
(Something that the ISP may even try to influence, but that ends up bringing 
more "childrens" to the support queue, as customers said, "Your company that 
recommended me to use software X instead of Y, so you have to teach me how to 
use software X".)
B) Lack of adequate support for IPv6 by the companies that provided the service 
on the internet (eGames, IPTV, SIP-VOIP).

After some time beating the dead horse, and mainly seeing that these problems 
did not happen with Dual-Stack, I decided to do what I was able to do well.

Since 1-2 years ago, things have improved a lot in these two points, pointed 
out as problems that do not concern the ISP.
Perhaps it is time to review this approach.

 

 

Em qua., 24 de fev. de 2021 às 18:35, Mark Andrews  escreveu:

Well then use one of the encapsulating IPv4AAS mechanisms rather than 464XLAT 
(DS-Lite, MAP-E). They don’t involve translating the payload between IPv4 and 
IPv6.  That said what you are reporting below are implementation bugs.  Did you 
report them to the vendor?  Did you install the fix?  Rewriting is required as 
you may have native IPv6 clients rather than clients behind a CLAT on the 
customer side.

> On 25 Feb 2021, at 01:48, Douglas Fischer  wrote:
> 
> 
> 
> Is this pain you have lived or verified with first hand testing?
> 
> Yep! A lot!
> 
> LOL gamers can be pretty much insistent...
> (haha.jpg +  haha-crying.jpg)
> 
> And Specifically on SIP/Voip over the Internet, with deep analysis at all the 
> parts involved.
> The most common issue is incoming Calls to SIP endpoints behi

Re: DualStack (CGNAT) vs Other Transition methods

[JORDI PALET MARTINEZ via NANOG]

I wish I could do it already! As soon as the client starts the massive 
deployment, it should be announced. Covid delayed it at least for 1 year up to 
now …

 

Regards,

Jordi

@jordipalet

 

 

 

El 6/4/21 7:07, "NANOG en nombre de Mark Tinka" 
 escribió:

 

 

On 4/5/21 22:00, JORDI PALET MARTINEZ via NANOG wrote:

 


Further to that, I’ve done a very complete testing, for a customer, with a PS4 
in a LAN with 464XLAT and everything worked fine. Unfortunately, as this was 
contracted by a customer, I can’t disclose all the test set, but believe me it 
worked. It is a deployment with 25.000.000 customers, using GPON, DSL and 
cellular.


Jordi, one of these days, you are going to have to tell us if this is real :-).

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: DualStack (CGNAT) vs Other Transition methods

[Mark Tinka]

On 4/5/21 21:30, Douglas Fischer wrote:


Here goes a link fo an excellent analysis of IPv6 and Playstation

This says a lot about why some prefer DualStack.

https://toreanderson.github.io/2021/02/23/ipv6-support-in-the-playstation-5.html 



Refusing to configure an IPv6 address because there is no IPv6 DNS 
resolver included in the SLAAC or DHCPv6 messages is very, very broken.


Mark.

Re: DualStack (CGNAT) vs Other Transition methods

[Mark Tinka]

On 4/5/21 22:00, JORDI PALET MARTINEZ via NANOG wrote:




Further to that, I’ve done a very complete testing, for a customer, 
with a PS4 in a LAN with 464XLAT and everything worked fine. 
Unfortunately, as this was contracted by a customer, I can’t disclose 
all the test set, but believe me it worked. It is a deployment with 
25.000.000 customers, using GPON, DSL and cellular.




Jordi, one of these days, you are going to have to tell us if this is 
real :-).


Mark.

Re: DualStack (CGNAT) vs Other Transition methods

[Douglas Fischer]

The important message on Tore's post IS ALL ABOUT "Sony and Playstation are
doing IPv6 in the wrong way!".

Em seg., 5 de abr. de 2021 às 19:16, Douglas Fischer <
fischerdoug...@gmail.com> escreveu:

> Jordi, If I sum the numbers of times "It is a deployment with 25.000.000
> customers, using GPON, DSL and cellular." (or similar)(EN, ES, PT) appears
> on my mail box, I guess will be over 2 hundred...
>
> But every time it hits on:
>  -> Support Tickets! What do they tell us?
>  -> Field Support and L1 Support Guys. Do they agree with that?
>
> Let me be clear:
> - I like IPv6!
> - I encourage the use of IPv6!
> - I think those guys that say "IPv6 won't be adopted" a bunch of lunatics!
>
> But, more important than IPv4, IPv6, "IPv12" is that my customers become
> happy and D'ONT BOTHER ME.
> If I would use IPX/SPX and get them even happier than they are today, I
> would do!
>
> The important message on Tore's post IS NOT "464XLAT is better then Dual
> Stack".
> The important message on Tore's post IS NOT "Sony and Playstation are
> doing IPv6 in the wrong way!".
>
> Could you please help every ISP, Every Gamer, demanding Sony and
> Playstation to do IPv6 the right way, without wanting to "seize the
> occasion" to publicize the IPv6 transition case and consultancy service?
>  Please? 
>
>
>
> Em seg., 5 de abr. de 2021 às 17:02, JORDI PALET MARTINEZ via NANOG <
> nanog@nanog.org> escreveu:
>
>> Hi Douglas,
>>
>>
>>
>> In a different mailing list, we had a discussion with Tore about his
>> testing and other testing that may not be available in that blog. It was
>> basically about 464XLAT.
>>
>>
>>
>> As you know IPv6-only with IPv4aaS, provides **dual-stack** in the
>> customer LANs, where the PS5 was sitting.
>>
>>
>>
>> So, we concluded in that discussion that there is **no difference** for
>> the PS5 being used with 464XLAT vs “regular dual-stack”, as expected.
>>
>>
>>
>> Further to that, I’ve done a very complete testing, for a customer, with
>> a PS4 in a LAN with 464XLAT and everything worked fine. Unfortunately, as
>> this was contracted by a customer, I can’t disclose all the test set, but
>> believe me it worked. It is a deployment with 25.000.000 customers, using
>> GPON, DSL and cellular.
>>
>>
>>
>>
>>
>> Regards,
>>
>> Jordi
>>
>> @jordipalet
>>
>>
>>
>>
>>
>>
>>
>> El 5/4/21 21:32, "NANOG en nombre de Douglas Fischer" <
>> nanog-bounces+jordi.palet=consulintel...@nanog.org en nombre de
>> fischerdoug...@gmail.com> escribió:
>>
>>
>>
>> Here goes a link fo an excellent analysis of IPv6 and Playstation
>>
>> This says a lot about why some prefer DualStack.
>>
>>
>> https://toreanderson.github.io/2021/02/23/ipv6-support-in-the-playstation-5.html
>>
>>
>>
>> Em ter., 2 de mar. de 2021 às 07:59, Douglas Fischer <
>> fischerdoug...@gmail.com> escreveu:
>>
>> Hello Mark...
>>
>> Yes, until when I was decided to Fight Agins IPv4, I tried the Fixes.
>>
>> But after some time, I saw that very little of the problems were due to
>> inadequacies of the ISP's responsibility equipment.
>>
>>
>> Most of the difficulties stemmed from:
>> A) Choices of end-users in their networks.
>> (Something that the ISP may even try to influence, but that ends up
>> bringing more "childrens" to the support queue, as customers said, "Your
>> company that recommended me to use software X instead of Y, so you have to
>> teach me how to use software X".)
>> B) Lack of adequate support for IPv6 by the companies that provided the
>> service on the internet (eGames, IPTV, SIP-VOIP).
>>
>> After some time beating the dead horse, and mainly seeing that these
>> problems did not happen with Dual-Stack, I decided to do what I was able to
>> do well.
>>
>> Since 1-2 years ago, things have improved a lot in these two points,
>> pointed out as problems that do not concern the ISP.
>> Perhaps it is time to review this approach.
>>
>>
>>
>>
>>
>> Em qua., 24 de fev. de 2021 às 18:35, Mark Andrews 
>> escreveu:
>>
>> Well then use one of the encapsulating IPv4AAS mechanisms rather than
>> 464XLAT (DS-Lite, MAP-E). They don’t involve translating the payload
>> between IPv4 and IPv6.  That said what you are reporting below are
>> implementation bugs.  Did you report them to the vendor?  Did you install
>> the fix?  Rewriting is required as you may have native IPv6 clients rather
>> than clients behind a CLAT on the customer side.
>>
>> > On 25 Feb 2021, at 01:48, Douglas Fischer 
>> wrote:
>> >
>> >
>> >
>> > Is this pain you have lived or verified with first hand testing?
>> >
>> > Yep! A lot!
>> >
>> > LOL gamers can be pretty much insistent...
>> > (haha.jpg +  haha-crying.jpg)
>> >
>> > And Specifically on SIP/Voip over the Internet, with deep analysis at
>> all the parts involved.
>> > The most common issue is incoming Calls to SIP endpoints behind 464Xlat
>> using IPv4 with unidirectional audio.
>> > And several types of causes:
>> >  - CPEs receives the RTP-Stream but doesn't Re-Map it correctly to the
>> IPv4 inside end-point
>> >  - 

Re: DualStack (CGNAT) vs Other Transition methods

[Douglas Fischer]

Jordi, If I sum the numbers of times "It is a deployment with 25.000.000
customers, using GPON, DSL and cellular." (or similar)(EN, ES, PT) appears
on my mail box, I guess will be over 2 hundred...

But every time it hits on:
 -> Support Tickets! What do they tell us?
 -> Field Support and L1 Support Guys. Do they agree with that?

Let me be clear:
- I like IPv6!
- I encourage the use of IPv6!
- I think those guys that say "IPv6 won't be adopted" a bunch of lunatics!

But, more important than IPv4, IPv6, "IPv12" is that my customers become
happy and D'ONT BOTHER ME.
If I would use IPX/SPX and get them even happier than they are today, I
would do!

The important message on Tore's post IS NOT "464XLAT is better then Dual
Stack".
The important message on Tore's post IS NOT "Sony and Playstation are doing
IPv6 in the wrong way!".

Could you please help every ISP, Every Gamer, demanding Sony and
Playstation to do IPv6 the right way, without wanting to "seize the
occasion" to publicize the IPv6 transition case and consultancy service?
 Please? 



Em seg., 5 de abr. de 2021 às 17:02, JORDI PALET MARTINEZ via NANOG <
nanog@nanog.org> escreveu:

> Hi Douglas,
>
>
>
> In a different mailing list, we had a discussion with Tore about his
> testing and other testing that may not be available in that blog. It was
> basically about 464XLAT.
>
>
>
> As you know IPv6-only with IPv4aaS, provides **dual-stack** in the
> customer LANs, where the PS5 was sitting.
>
>
>
> So, we concluded in that discussion that there is **no difference** for
> the PS5 being used with 464XLAT vs “regular dual-stack”, as expected.
>
>
>
> Further to that, I’ve done a very complete testing, for a customer, with a
> PS4 in a LAN with 464XLAT and everything worked fine. Unfortunately, as
> this was contracted by a customer, I can’t disclose all the test set, but
> believe me it worked. It is a deployment with 25.000.000 customers, using
> GPON, DSL and cellular.
>
>
>
>
>
> Regards,
>
> Jordi
>
> @jordipalet
>
>
>
>
>
>
>
> El 5/4/21 21:32, "NANOG en nombre de Douglas Fischer" <
> nanog-bounces+jordi.palet=consulintel...@nanog.org en nombre de
> fischerdoug...@gmail.com> escribió:
>
>
>
> Here goes a link fo an excellent analysis of IPv6 and Playstation
>
> This says a lot about why some prefer DualStack.
>
>
> https://toreanderson.github.io/2021/02/23/ipv6-support-in-the-playstation-5.html
>
>
>
> Em ter., 2 de mar. de 2021 às 07:59, Douglas Fischer <
> fischerdoug...@gmail.com> escreveu:
>
> Hello Mark...
>
> Yes, until when I was decided to Fight Agins IPv4, I tried the Fixes.
>
> But after some time, I saw that very little of the problems were due to
> inadequacies of the ISP's responsibility equipment.
>
>
> Most of the difficulties stemmed from:
> A) Choices of end-users in their networks.
> (Something that the ISP may even try to influence, but that ends up
> bringing more "childrens" to the support queue, as customers said, "Your
> company that recommended me to use software X instead of Y, so you have to
> teach me how to use software X".)
> B) Lack of adequate support for IPv6 by the companies that provided the
> service on the internet (eGames, IPTV, SIP-VOIP).
>
> After some time beating the dead horse, and mainly seeing that these
> problems did not happen with Dual-Stack, I decided to do what I was able to
> do well.
>
> Since 1-2 years ago, things have improved a lot in these two points,
> pointed out as problems that do not concern the ISP.
> Perhaps it is time to review this approach.
>
>
>
>
>
> Em qua., 24 de fev. de 2021 às 18:35, Mark Andrews 
> escreveu:
>
> Well then use one of the encapsulating IPv4AAS mechanisms rather than
> 464XLAT (DS-Lite, MAP-E). They don’t involve translating the payload
> between IPv4 and IPv6.  That said what you are reporting below are
> implementation bugs.  Did you report them to the vendor?  Did you install
> the fix?  Rewriting is required as you may have native IPv6 clients rather
> than clients behind a CLAT on the customer side.
>
> > On 25 Feb 2021, at 01:48, Douglas Fischer 
> wrote:
> >
> >
> >
> > Is this pain you have lived or verified with first hand testing?
> >
> > Yep! A lot!
> >
> > LOL gamers can be pretty much insistent...
> > (haha.jpg +  haha-crying.jpg)
> >
> > And Specifically on SIP/Voip over the Internet, with deep analysis at
> all the parts involved.
> > The most common issue is incoming Calls to SIP endpoints behind 464Xlat
> using IPv4 with unidirectional audio.
> > And several types of causes:
> >  - CPEs receives the RTP-Stream but doesn't Re-Map it correctly to the
> IPv4 inside end-point
> >  - Jool receives the RTP-Stream but ignores it and don't map it to the
> "fake" v6 address
> >  - Some APPs do (by some crazy reason) the re-write of Session Layer
> header to v6 address, and Sip-Proxys ignores it...
> >
> > After hours and hours fighting against the lions, we decided:
> > "Let's keep those clients in Dual-Stak and CGNAT" and it just worked.
> >
> > And after 

Re: DualStack (CGNAT) vs Other Transition methods

[JORDI PALET MARTINEZ via NANOG]

Hi Douglas,

 

In a different mailing list, we had a discussion with Tore about his testing 
and other testing that may not be available in that blog. It was basically 
about 464XLAT.

 

As you know IPv6-only with IPv4aaS, provides *dual-stack* in the customer LANs, 
where the PS5 was sitting.

 

So, we concluded in that discussion that there is *no difference* for the PS5 
being used with 464XLAT vs “regular dual-stack”, as expected.

 

Further to that, I’ve done a very complete testing, for a customer, with a PS4 
in a LAN with 464XLAT and everything worked fine. Unfortunately, as this was 
contracted by a customer, I can’t disclose all the test set, but believe me it 
worked. It is a deployment with 25.000.000 customers, using GPON, DSL and 
cellular.

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 5/4/21 21:32, "NANOG en nombre de Douglas Fischer" 
 escribió:

 

Here goes a link fo an excellent analysis of IPv6 and Playstation

This says a lot about why some prefer DualStack.

https://toreanderson.github.io/2021/02/23/ipv6-support-in-the-playstation-5.html

 

Em ter., 2 de mar. de 2021 às 07:59, Douglas Fischer  
escreveu:

Hello Mark...

Yes, until when I was decided to Fight Agins IPv4, I tried the Fixes.

But after some time, I saw that very little of the problems were due to 
inadequacies of the ISP's responsibility equipment.


Most of the difficulties stemmed from:
A) Choices of end-users in their networks.
(Something that the ISP may even try to influence, but that ends up bringing 
more "childrens" to the support queue, as customers said, "Your company that 
recommended me to use software X instead of Y, so you have to teach me how to 
use software X".)
B) Lack of adequate support for IPv6 by the companies that provided the service 
on the internet (eGames, IPTV, SIP-VOIP).

After some time beating the dead horse, and mainly seeing that these problems 
did not happen with Dual-Stack, I decided to do what I was able to do well.

Since 1-2 years ago, things have improved a lot in these two points, pointed 
out as problems that do not concern the ISP.
Perhaps it is time to review this approach.

 

 

Em qua., 24 de fev. de 2021 às 18:35, Mark Andrews  escreveu:

Well then use one of the encapsulating IPv4AAS mechanisms rather than 464XLAT 
(DS-Lite, MAP-E). They don’t involve translating the payload between IPv4 and 
IPv6.  That said what you are reporting below are implementation bugs.  Did you 
report them to the vendor?  Did you install the fix?  Rewriting is required as 
you may have native IPv6 clients rather than clients behind a CLAT on the 
customer side.

> On 25 Feb 2021, at 01:48, Douglas Fischer  wrote:
> 
> 
> 
> Is this pain you have lived or verified with first hand testing?
> 
> Yep! A lot!
> 
> LOL gamers can be pretty much insistent...
> (haha.jpg +  haha-crying.jpg)
> 
> And Specifically on SIP/Voip over the Internet, with deep analysis at all the 
> parts involved.
> The most common issue is incoming Calls to SIP endpoints behind 464Xlat using 
> IPv4 with unidirectional audio.
> And several types of causes:
>  - CPEs receives the RTP-Stream but doesn't Re-Map it correctly to the IPv4 
> inside end-point
>  - Jool receives the RTP-Stream but ignores it and don't map it to the "fake" 
> v6 address
>  - Some APPs do (by some crazy reason) the re-write of Session Layer header 
> to v6 address, and Sip-Proxys ignores it...
> 
> After hours and hours fighting against the lions, we decided:
> "Let's keep those clients in Dual-Stak and CGNAT" and it just worked.
> 
> And after that, the obvious conclusions:
>  - Why will us keep that much options of endpoints connections, if only one 
> solves all the problems?
>  - We will need to train the guys on the Dual-Stack/CGNAT Scnario, and 
> 464Xlat Scenario... Knowing about Danos, about Jool...
>  - It doesn't scale!
> 
> 
> -- 
> Douglas Fernando Fischer
> Engº de Controle e Automação

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org


 

-- 

Douglas Fernando Fischer
Engº de Controle e Automação


 

-- 

Douglas Fernando Fischer
Engº de Controle e Automação



**
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 y

Re: DualStack (CGNAT) vs Other Transition methods

[Douglas Fischer]

Here goes a link fo an excellent analysis of IPv6 and Playstation

This says a lot about why some prefer DualStack.

https://toreanderson.github.io/2021/02/23/ipv6-support-in-the-playstation-5.html


Em ter., 2 de mar. de 2021 às 07:59, Douglas Fischer <
fischerdoug...@gmail.com> escreveu:

> Hello Mark...
>
> Yes, until when I was decided to Fight Agins IPv4, I tried the Fixes.
>
> But after some time, I saw that very little of the problems were due to
> inadequacies of the ISP's responsibility equipment.
>
> Most of the difficulties stemmed from:
> A) Choices of end-users in their networks.
> (Something that the ISP may even try to influence, but that ends up
> bringing more "childrens" to the support queue, as customers said, "Your
> company that recommended me to use software X instead of Y, so you have to
> teach me how to use software X".)
> B) Lack of adequate support for IPv6 by the companies that provided the
> service on the internet (eGames, IPTV, SIP-VOIP).
>
> After some time beating the dead horse, and mainly seeing that these
> problems did not happen with Dual-Stack, I decided to do what I was able to
> do well.
>
> Since 1-2 years ago, things have improved a lot in these two points,
> pointed out as problems that do not concern the ISP.
> Perhaps it is time to review this approach.
>
>
> Em qua., 24 de fev. de 2021 às 18:35, Mark Andrews 
> escreveu:
>
>> Well then use one of the encapsulating IPv4AAS mechanisms rather than
>> 464XLAT (DS-Lite, MAP-E). They don’t involve translating the payload
>> between IPv4 and IPv6.  That said what you are reporting below are
>> implementation bugs.  Did you report them to the vendor?  Did you install
>> the fix?  Rewriting is required as you may have native IPv6 clients rather
>> than clients behind a CLAT on the customer side.
>>
>> > On 25 Feb 2021, at 01:48, Douglas Fischer 
>> wrote:
>> >
>> >
>> >
>> > Is this pain you have lived or verified with first hand testing?
>> >
>> > Yep! A lot!
>> >
>> > LOL gamers can be pretty much insistent...
>> > (haha.jpg +  haha-crying.jpg)
>> >
>> > And Specifically on SIP/Voip over the Internet, with deep analysis at
>> all the parts involved.
>> > The most common issue is incoming Calls to SIP endpoints behind 464Xlat
>> using IPv4 with unidirectional audio.
>> > And several types of causes:
>> >  - CPEs receives the RTP-Stream but doesn't Re-Map it correctly to the
>> IPv4 inside end-point
>> >  - Jool receives the RTP-Stream but ignores it and don't map it to the
>> "fake" v6 address
>> >  - Some APPs do (by some crazy reason) the re-write of Session Layer
>> header to v6 address, and Sip-Proxys ignores it...
>> >
>> > After hours and hours fighting against the lions, we decided:
>> > "Let's keep those clients in Dual-Stak and CGNAT" and it just worked.
>> >
>> > And after that, the obvious conclusions:
>> >  - Why will us keep that much options of endpoints connections, if only
>> one solves all the problems?
>> >  - We will need to train the guys on the Dual-Stack/CGNAT Scnario, and
>> 464Xlat Scenario... Knowing about Danos, about Jool...
>> >  - It doesn't scale!
>> >
>> >
>> > --
>> > Douglas Fernando Fischer
>> > Engº de Controle e Automação
>>
>> --
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
>>
>>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
>


-- 
Douglas Fernando Fischer
Engº de Controle e Automação

Re: DualStack (CGNAT) vs Other Transition methods

[Douglas Fischer]

Hello Mark...

Yes, until when I was decided to Fight Agins IPv4, I tried the Fixes.

But after some time, I saw that very little of the problems were due to
inadequacies of the ISP's responsibility equipment.

Most of the difficulties stemmed from:
A) Choices of end-users in their networks.
(Something that the ISP may even try to influence, but that ends up
bringing more "childrens" to the support queue, as customers said, "Your
company that recommended me to use software X instead of Y, so you have to
teach me how to use software X".)
B) Lack of adequate support for IPv6 by the companies that provided the
service on the internet (eGames, IPTV, SIP-VOIP).

After some time beating the dead horse, and mainly seeing that these
problems did not happen with Dual-Stack, I decided to do what I was able to
do well.

Since 1-2 years ago, things have improved a lot in these two points,
pointed out as problems that do not concern the ISP.
Perhaps it is time to review this approach.


Em qua., 24 de fev. de 2021 às 18:35, Mark Andrews  escreveu:

> Well then use one of the encapsulating IPv4AAS mechanisms rather than
> 464XLAT (DS-Lite, MAP-E). They don’t involve translating the payload
> between IPv4 and IPv6.  That said what you are reporting below are
> implementation bugs.  Did you report them to the vendor?  Did you install
> the fix?  Rewriting is required as you may have native IPv6 clients rather
> than clients behind a CLAT on the customer side.
>
> > On 25 Feb 2021, at 01:48, Douglas Fischer 
> wrote:
> >
> >
> >
> > Is this pain you have lived or verified with first hand testing?
> >
> > Yep! A lot!
> >
> > LOL gamers can be pretty much insistent...
> > (haha.jpg +  haha-crying.jpg)
> >
> > And Specifically on SIP/Voip over the Internet, with deep analysis at
> all the parts involved.
> > The most common issue is incoming Calls to SIP endpoints behind 464Xlat
> using IPv4 with unidirectional audio.
> > And several types of causes:
> >  - CPEs receives the RTP-Stream but doesn't Re-Map it correctly to the
> IPv4 inside end-point
> >  - Jool receives the RTP-Stream but ignores it and don't map it to the
> "fake" v6 address
> >  - Some APPs do (by some crazy reason) the re-write of Session Layer
> header to v6 address, and Sip-Proxys ignores it...
> >
> > After hours and hours fighting against the lions, we decided:
> > "Let's keep those clients in Dual-Stak and CGNAT" and it just worked.
> >
> > And after that, the obvious conclusions:
> >  - Why will us keep that much options of endpoints connections, if only
> one solves all the problems?
> >  - We will need to train the guys on the Dual-Stack/CGNAT Scnario, and
> 464Xlat Scenario... Knowing about Danos, about Jool...
> >  - It doesn't scale!
> >
> >
> > --
> > Douglas Fernando Fischer
> > Engº de Controle e Automação
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
>
>

-- 
Douglas Fernando Fischer
Engº de Controle e Automação

Re: DualStack (CGNAT) vs Other Transition methods

[Mark Andrews]

Well then use one of the encapsulating IPv4AAS mechanisms rather than 464XLAT 
(DS-Lite, MAP-E). They don’t involve translating the payload between IPv4 and 
IPv6.  That said what you are reporting below are implementation bugs.  Did you 
report them to the vendor?  Did you install the fix?  Rewriting is required as 
you may have native IPv6 clients rather than clients behind a CLAT on the 
customer side.

> On 25 Feb 2021, at 01:48, Douglas Fischer  wrote:
> 
> 
> 
> Is this pain you have lived or verified with first hand testing?
> 
> Yep! A lot!
> 
> LOL gamers can be pretty much insistent...
> (haha.jpg +  haha-crying.jpg)
> 
> And Specifically on SIP/Voip over the Internet, with deep analysis at all the 
> parts involved.
> The most common issue is incoming Calls to SIP endpoints behind 464Xlat using 
> IPv4 with unidirectional audio.
> And several types of causes:
>  - CPEs receives the RTP-Stream but doesn't Re-Map it correctly to the IPv4 
> inside end-point
>  - Jool receives the RTP-Stream but ignores it and don't map it to the "fake" 
> v6 address
>  - Some APPs do (by some crazy reason) the re-write of Session Layer header 
> to v6 address, and Sip-Proxys ignores it...
> 
> After hours and hours fighting against the lions, we decided:
> "Let's keep those clients in Dual-Stak and CGNAT" and it just worked.
> 
> And after that, the obvious conclusions:
>  - Why will us keep that much options of endpoints connections, if only one 
> solves all the problems?
>  - We will need to train the guys on the Dual-Stack/CGNAT Scnario, and 
> 464Xlat Scenario... Knowing about Danos, about Jool...
>  - It doesn't scale!
> 
> 
> -- 
> Douglas Fernando Fischer
> Engº de Controle e Automação

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

Re: DualStack (CGNAT) vs Other Transition methods

[Douglas Fischer]

>
> Is this pain you have lived or verified with first hand testing?
>
>>
>> Yep! A lot!

LOL gamers can be pretty much insistent...
(haha.jpg +  haha-crying.jpg)

And Specifically on SIP/Voip over the Internet, with deep analysis at all
the parts involved.
The most common issue is incoming Calls to SIP endpoints behind 464Xlat
using IPv4 with unidirectional audio.
And several types of causes:
 - CPEs receives the RTP-Stream but doesn't Re-Map it correctly to the IPv4
inside end-point
 - Jool receives the RTP-Stream but ignores it and don't map it to the
"fake" v6 address
 - Some APPs do (by some crazy reason) the re-write of Session Layer header
to v6 address, and Sip-Proxys ignores it...

After hours and hours fighting against the lions, we decided:
"Let's keep those clients in Dual-Stak and CGNAT" and it just worked.

And after that, the obvious conclusions:
 - Why will us keep that much options of endpoints connections, if only one
solves all the problems?
 - We will need to train the guys on the Dual-Stack/CGNAT Scnario, and
464Xlat Scenario... Knowing about Danos, about Jool...
 - It doesn't scale!


-- 
Douglas Fernando Fischer
Engº de Controle e Automação

Re: DualStack (CGNAT) vs Other Transition methods

[JORDI PALET MARTINEZ via NANOG]

Hi Douglas,

 

I’ve done a lot of testing in several countries and customer networks and I’ve 
never got a single failure because 464XLAT.

 

If anything failed, we tested it with a pure IPv4 network and dual-stack 
network. They failed as well.

 

For example, I recall, in a customer deployment, that PlayStation 4 was not 
working … surprise. It was a specific problem *at that specific time*, so it 
was also not working with IPv4-only. Retested a couple of days after, and it 
worked.

 

I talk very frequently with other engineers which have also deployed 464XLAT in 
both cellular and wireline, and I’ve never heard any complain about any 
specific application or service not working because 464XLAT, so I’m not alone 
on this.

 

So, I think experience talk. Probably the question is about the same as you’re 
indicating “good quality” (whatever, including experience in the matter), makes 
things work without issues!

 

Regards,

Jordi

@jordipalet

 

 

 

El 24/2/21 14:28, "Douglas Fischer"  escribió:

 

P.S.: Forking thread from CGNAT.

Hello Jordi!

Since our last heated talk about transitions methods(Rosario, 2018?), I must 
recognize that the intolerance to other scenarios other than dual-stack had 
reduced(mostly because of improvements on the applications in generral). I'm 
even considering the possibility of using 464Xlat on some scenarios.


But I'm still, as it was in 2018, primarily concerned to avoid end-user support 
tickets.

And I'm still hooked on some specific issues... For example:
- SIP/Voip Applications, that almost all the providers do not work correctly on 
when those streams and connections pass over some v6 only paths.

- Applications with some source-based restrictions(some Internet Banking, some 
Compan-VPNs).

- Games (this is the champion of support tickets).

For that, with 464Xlat we still keep in pain...
But using DualStack with Good Quality CGNAT, the support tickets statistics are 
reduced to less than 5%.


So, the question here is:
How not use Dual-Stack and keep the support tickets as low as possible?


* "Good Quality CGNAT" means:
 - OBVIOUSLY have an extensive, deep, and GOOD deployment of IPv6(to avoid as 
much as possible the use of IPv4)
 - Good rules of CGNAT By-Pass (Ex.: Traffic between customers and Internal 
Servers don't need to be NATed.)
 - CGNAT with support to PCP, UPnP, and NAT-Algs. Preferably BPA - Bulk Port 
Allocation.

 

Em qua., 24 de fev. de 2021 às 04:11, JORDI PALET MARTINEZ via NANOG 
 escreveu:

I did this "economics" exercise for a customer having 25.000.000 customers 
(DSL, GPON and cellular). Even updating/replacing the CPEs, the cost of 464XLAT 
deployment was cheaper than CGN or anything else.

Also, if you consider the cost of buying more IPv4 addresses instead of 
investing that money in CGN, you avoid CGN troubles (like black listening your 
IPv4 addresses by Sony and others and the consequently operation/management 
expenses to rotate IPv4 addresses in the CGN, resolve customers problems, 
etc.), it becomes cheaper than CGN boxes.

It's easy to predict that you will buy now CGN and tomorrow you will need to 
buy some new IPv4 addresses because that black listening.

Regards,
Jordi
@jordipalet



El 24/2/21 3:13, "NANOG en nombre de Owen DeLong via NANOG" 
 escribió:



> On Feb 22, 2021, at 6:44 AM, na...@jima.us wrote:
> 
> While I don't doubt the accuracy of Lee's presentation at the time, at 
least two base factors have changed since then:
> 
> - Greater deployment of IPv6 content (necessitating less CGN capacity per 
user)

This is only true if the ISP in question is implementing IPv6 along side 
their CGN deployment and only if they get a significant uptake of IPv6 
capability by their end users.

> - Increased price of Legacy IP space on the secondary market (changing 
the formula) -- strictly speaking, this presentation was still in "primary 
market" era for LACNIC/ARIN/AFRINIC

While that’s true, even at current prices, IPv4 addresses are cheaper to 
buy and/or lease than CGN.

> IPv6 migration is not generally aided by CGNAT, but CGNAT deployment is 
generally aided by IPv6 deployment; to reiterate the earlier point, any ISPs 
deploying CGNAT without first deploying IPv6 are burning cash.

Yep.

I still think that implementing CGN is a good way to burn cash vs. the 
alternatives, but YMMV.

Owen

> 
> - Jima
> 
> From: NANOG On Behalf Of Owen DeLong
> Sent: Sunday, February 21, 2021 16:59
> To: Steve Saner
> Cc: nanog@nanog.org
> Subject: Re: CGNAT
> 
> 
> On Feb 18, 2021, at 8:38 AM, Steve Saner wrote:
> 
>> We are starting to look at CGNAT solutions. The primary motivation at 
the moment is to extend current IPv4 resources, but IPv6 migration is also a 
factor.
> 
> IPv6 Migration is generally not aided by CGNAT.
> 
> In general, the economics today still work out to make purchasing or 
leasing addresse

Re: DualStack (CGNAT) vs Other Transition methods

[Ca By]

On Wed, Feb 24, 2021 at 5:29 AM Douglas Fischer 
wrote:

> P.S.: Forking thread from CGNAT.
>
> Hello Jordi!
>
> Since our last heated talk about transitions methods(Rosario, 2018?), I
> must recognize that the intolerance to other scenarios other than
> dual-stack had reduced(mostly because of improvements on the applications
> in generral). I'm even considering the possibility of using 464Xlat on some
> scenarios.
>
> But I'm still, as it was in 2018, primarily concerned to avoid end-user
> support tickets.
>
> And I'm still hooked on some specific issues... For example:
> - SIP/Voip Applications, that almost all the providers do not work
> correctly on when those streams and connections pass over some v6 only
> paths.
> - Applications with some source-based restrictions(some Internet Banking,
> some Compan-VPNs).
> - Games (this is the champion of support tickets).
>
> For that, with 464Xlat we still keep in pain...
>

Is this pain you have lived or verified with first hand testing?

I am operate 464xlat broadband network, and do not have this pain in the
general case. That said, there are cpe specific qa concerns, but that is
always the case, regardless of tech


> But using DualStack with Good Quality CGNAT, the support tickets
> statistics are reduced to less than 5%.
>
>
> So, the question here is:
> How not use Dual-Stack and keep the support tickets as low as possible?
>
>
> * "Good Quality CGNAT" means:
>  - OBVIOUSLY have an extensive, deep, and GOOD deployment of IPv6(to avoid
> as much as possible the use of IPv4)
>  - Good rules of CGNAT By-Pass (Ex.: Traffic between customers and
> Internal Servers don't need to be NATed.)
>  - CGNAT with support to PCP, UPnP, and NAT-Algs. Preferably BPA - Bulk
> Port Allocation.
>
>
> Em qua., 24 de fev. de 2021 às 04:11, JORDI PALET MARTINEZ via NANOG <
> nanog@nanog.org> escreveu:
>
>> I did this "economics" exercise for a customer having 25.000.000
>> customers (DSL, GPON and cellular). Even updating/replacing the CPEs, the
>> cost of 464XLAT deployment was cheaper than CGN or anything else.
>>
>> Also, if you consider the cost of buying more IPv4 addresses instead of
>> investing that money in CGN, you avoid CGN troubles (like black listening
>> your IPv4 addresses by Sony and others and the consequently
>> operation/management expenses to rotate IPv4 addresses in the CGN, resolve
>> customers problems, etc.), it becomes cheaper than CGN boxes.
>>
>> It's easy to predict that you will buy now CGN and tomorrow you will need
>> to buy some new IPv4 addresses because that black listening.
>>
>> Regards,
>> Jordi
>> @jordipalet
>>
>>
>>
>> El 24/2/21 3:13, "NANOG en nombre de Owen DeLong via NANOG"
>> > nanog@nanog.org> escribió:
>>
>>
>>
>> > On Feb 22, 2021, at 6:44 AM, na...@jima.us wrote:
>> >
>> > While I don't doubt the accuracy of Lee's presentation at the time,
>> at least two base factors have changed since then:
>> >
>> > - Greater deployment of IPv6 content (necessitating less CGN
>> capacity per user)
>>
>> This is only true if the ISP in question is implementing IPv6 along
>> side their CGN deployment and only if they get a significant uptake of IPv6
>> capability by their end users.
>>
>> > - Increased price of Legacy IP space on the secondary market
>> (changing the formula) -- strictly speaking, this presentation was still in
>> "primary market" era for LACNIC/ARIN/AFRINIC
>>
>> While that’s true, even at current prices, IPv4 addresses are cheaper
>> to buy and/or lease than CGN.
>>
>> > IPv6 migration is not generally aided by CGNAT, but CGNAT
>> deployment is generally aided by IPv6 deployment; to reiterate the earlier
>> point, any ISPs deploying CGNAT without first deploying IPv6 are burning
>> cash.
>>
>> Yep.
>>
>> I still think that implementing CGN is a good way to burn cash vs.
>> the alternatives, but YMMV.
>>
>> Owen
>>
>> >
>> > - Jima
>> >
>> > From: NANOG On Behalf Of Owen DeLong
>> > Sent: Sunday, February 21, 2021 16:59
>> > To: Steve Saner
>> > Cc: nanog@nanog.org
>> > Subject: Re: CGNAT
>> >
>> >
>> > On Feb 18, 2021, at 8:38 AM, Steve Saner wrote:
>> >
>> >> We are starting to look at CGNAT solutions. The primary motivation
>> at the moment is to extend current IPv4 resources, but IPv6 migration is
>> also a factor.
>> >
>> > IPv6 Migration is generally not aided by CGNAT.
>> >
>> > In general, the economics today still work out to make purchasing
>> or leasing addresses more favorable than CGNAT.
>> >
>> > It’s a bit dated by now, but still very relevant, see Lee Howard’s
>> excellent research presented at the 2012 Rocky
>> > mountain v6 task force meeting:
>> >
>> > https://www.rmv6tf.org/wp-content/uploads/2012/11/TCO-of-CGN1.pdf
>> >
>> > Owen
>> >
>> >
>> > We've been in touch with A10. Just wondering if there are some
>> alternative vendors that anyone would rec

DualStack (CGNAT) vs Other Transition methods

[Douglas Fischer]

P.S.: Forking thread from CGNAT.

Hello Jordi!

Since our last heated talk about transitions methods(Rosario, 2018?), I
must recognize that the intolerance to other scenarios other than
dual-stack had reduced(mostly because of improvements on the applications
in generral). I'm even considering the possibility of using 464Xlat on some
scenarios.

But I'm still, as it was in 2018, primarily concerned to avoid end-user
support tickets.

And I'm still hooked on some specific issues... For example:
- SIP/Voip Applications, that almost all the providers do not work
correctly on when those streams and connections pass over some v6 only
paths.
- Applications with some source-based restrictions(some Internet Banking,
some Compan-VPNs).
- Games (this is the champion of support tickets).

For that, with 464Xlat we still keep in pain...
But using DualStack with Good Quality CGNAT, the support tickets statistics
are reduced to less than 5%.


So, the question here is:
How not use Dual-Stack and keep the support tickets as low as possible?


* "Good Quality CGNAT" means:
 - OBVIOUSLY have an extensive, deep, and GOOD deployment of IPv6(to avoid
as much as possible the use of IPv4)
 - Good rules of CGNAT By-Pass (Ex.: Traffic between customers and Internal
Servers don't need to be NATed.)
 - CGNAT with support to PCP, UPnP, and NAT-Algs. Preferably BPA - Bulk
Port Allocation.


Em qua., 24 de fev. de 2021 às 04:11, JORDI PALET MARTINEZ via NANOG <
nanog@nanog.org> escreveu:

> I did this "economics" exercise for a customer having 25.000.000 customers
> (DSL, GPON and cellular). Even updating/replacing the CPEs, the cost of
> 464XLAT deployment was cheaper than CGN or anything else.
>
> Also, if you consider the cost of buying more IPv4 addresses instead of
> investing that money in CGN, you avoid CGN troubles (like black listening
> your IPv4 addresses by Sony and others and the consequently
> operation/management expenses to rotate IPv4 addresses in the CGN, resolve
> customers problems, etc.), it becomes cheaper than CGN boxes.
>
> It's easy to predict that you will buy now CGN and tomorrow you will need
> to buy some new IPv4 addresses because that black listening.
>
> Regards,
> Jordi
> @jordipalet
>
>
>
> El 24/2/21 3:13, "NANOG en nombre de Owen DeLong via NANOG"
>  nanog@nanog.org> escribió:
>
>
>
> > On Feb 22, 2021, at 6:44 AM, na...@jima.us wrote:
> >
> > While I don't doubt the accuracy of Lee's presentation at the time,
> at least two base factors have changed since then:
> >
> > - Greater deployment of IPv6 content (necessitating less CGN
> capacity per user)
>
> This is only true if the ISP in question is implementing IPv6 along
> side their CGN deployment and only if they get a significant uptake of IPv6
> capability by their end users.
>
> > - Increased price of Legacy IP space on the secondary market
> (changing the formula) -- strictly speaking, this presentation was still in
> "primary market" era for LACNIC/ARIN/AFRINIC
>
> While that’s true, even at current prices, IPv4 addresses are cheaper
> to buy and/or lease than CGN.
>
> > IPv6 migration is not generally aided by CGNAT, but CGNAT deployment
> is generally aided by IPv6 deployment; to reiterate the earlier point, any
> ISPs deploying CGNAT without first deploying IPv6 are burning cash.
>
> Yep.
>
> I still think that implementing CGN is a good way to burn cash vs. the
> alternatives, but YMMV.
>
> Owen
>
> >
> > - Jima
> >
> > From: NANOG On Behalf Of Owen DeLong
> > Sent: Sunday, February 21, 2021 16:59
> > To: Steve Saner
> > Cc: nanog@nanog.org
> > Subject: Re: CGNAT
> >
> >
> > On Feb 18, 2021, at 8:38 AM, Steve Saner wrote:
> >
> >> We are starting to look at CGNAT solutions. The primary motivation
> at the moment is to extend current IPv4 resources, but IPv6 migration is
> also a factor.
> >
> > IPv6 Migration is generally not aided by CGNAT.
> >
> > In general, the economics today still work out to make purchasing or
> leasing addresses more favorable than CGNAT.
> >
> > It’s a bit dated by now, but still very relevant, see Lee Howard’s
> excellent research presented at the 2012 Rocky
> > mountain v6 task force meeting:
> >
> > https://www.rmv6tf.org/wp-content/uploads/2012/11/TCO-of-CGN1.pdf
> >
> > Owen
> >
> >
> > We've been in touch with A10. Just wondering if there are some
> alternative vendors that anyone would recommend. We'd probably be looking
> at a solution to support 5k to 15k customers and bandwidth up to around
> 30-40 gig as a starting point. A solution that is as transparent to user
> experience as possible is a priority.
> >
> > Thanks
> >
> > --
> > Steve Saner
> > ideatek HUMAN AT OUR VERY FIBER
> > This email transmission, and any documents, files or previous email
> messages attached to it may contain confidential information. If the r