Re: IPv6 and forensic requests
Apple doesn't use CLAT, because apps should support IPv6-only since a couple of year ago. If they don't something "close" to a CLAT is done by RFC8305. If is doing tethering, then the CLAT is done towards the tethered devices. Regards, Jordi -Mensaje original- De: NANOG en nombre de Max Tulyev Fecha: domingo, 10 de febrero de 2019, 19:21 Para: NANOG Asunto: Re: IPv6 and forensic requests Great, thank you! Did you manage to whitelist APN at Apple so iOS devices can use it too? 10.02.19 20:06, JORDI PALET MARTINEZ пише: > Well, if it is mobile, then definitively you should use /64 for every PDP context, and clearly is NAT64. > > In this case, you don't need to take care about the CLAT part, just look at the /64 prefix for the logging. > > Make sure to talk about stateful NAT64 ... otherwise you create lot of confusion. > > You've some deployment hints at > https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ > > Also, google for some of my IPv6-only tutorials (last RIPE meeting, APNIC meeting, etc., there are even videos of them). > > Regards, > Jordi > > > > -Mensaje original- > De: NANOG en nombre de Max Tulyev > Fecha: domingo, 10 de febrero de 2019, 16:30 > CC: NANOG > Asunto: Re: IPv6 and forensic requests > > Hello Jordi, > > thank you, I will take a look on Jool! > > Exactly CLAT was the issue. > > First, I thought to provide a /128 to every mobile, and then do a static > 6to4 to certain public IPv4. But it seems mobile need a /64, and it uses > a lot of random IPv6 inside assigned /64, several addresses together at > each time, CLAT uses the most of it (on Android). So direct translation > 6->public4 is impossible. > > 10.02.19 15:51, JORDI PALET MARTINEZ пише: > > Do you really mean 6to4 or NAT64? Totally different things ... > > > > If that's the case, I will suggest you go for Jool instead of Tayga. > > > > Also, if you want the customers are able to use old IPv4 apps and devices, NAT64 is not sufficient, you need also CLAT at the customer premises (so they can run 464XLAT). > > > > Regards, > > Jordi > > > > > > > > -Mensaje original- > > De: NANOG en nombre de Max Tulyev > > Fecha: domingo, 10 de febrero de 2019, 14:26 > > Para: NANOG > > Asunto: IPv6 and forensic requests > > > > Hi All, > > > > we are implementing IPv6 only infrastructure. > > > > For IPv4 access, we using tayga for 6to4 translation and then CGN for NAT. > > > > There is a number of ways for Linux based NAT to store information for > > future forensic requests (i.e. "who was it cracking that website?"). > > > > But what about 6to4 translators, as tayga? I believe there should be > > well-known patches or solutions. The aim is to have what /64 (not even > > /128) was translated to what IPv4 at the requested time. > > > > Is there any? > > > > > > > > > > ** > > 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 and forensic requests
Great, thank you! Did you manage to whitelist APN at Apple so iOS devices can use it too? 10.02.19 20:06, JORDI PALET MARTINEZ пише: Well, if it is mobile, then definitively you should use /64 for every PDP context, and clearly is NAT64. In this case, you don't need to take care about the CLAT part, just look at the /64 prefix for the logging. Make sure to talk about stateful NAT64 ... otherwise you create lot of confusion. You've some deployment hints at https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ Also, google for some of my IPv6-only tutorials (last RIPE meeting, APNIC meeting, etc., there are even videos of them). Regards, Jordi -Mensaje original- De: NANOG en nombre de Max Tulyev Fecha: domingo, 10 de febrero de 2019, 16:30 CC: NANOG Asunto: Re: IPv6 and forensic requests Hello Jordi, thank you, I will take a look on Jool! Exactly CLAT was the issue. First, I thought to provide a /128 to every mobile, and then do a static 6to4 to certain public IPv4. But it seems mobile need a /64, and it uses a lot of random IPv6 inside assigned /64, several addresses together at each time, CLAT uses the most of it (on Android). So direct translation 6->public4 is impossible. 10.02.19 15:51, JORDI PALET MARTINEZ пише: > Do you really mean 6to4 or NAT64? Totally different things ... > > If that's the case, I will suggest you go for Jool instead of Tayga. > > Also, if you want the customers are able to use old IPv4 apps and devices, NAT64 is not sufficient, you need also CLAT at the customer premises (so they can run 464XLAT). > > Regards, > Jordi > > > > -Mensaje original- > De: NANOG en nombre de Max Tulyev > Fecha: domingo, 10 de febrero de 2019, 14:26 > Para: NANOG > Asunto: IPv6 and forensic requests > > Hi All, > > we are implementing IPv6 only infrastructure. > > For IPv4 access, we using tayga for 6to4 translation and then CGN for NAT. > > There is a number of ways for Linux based NAT to store information for > future forensic requests (i.e. "who was it cracking that website?"). > > But what about 6to4 translators, as tayga? I believe there should be > well-known patches or solutions. The aim is to have what /64 (not even > /128) was translated to what IPv4 at the requested time. > > Is there any? > > > > > ** > 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 and forensic requests
Well, if it is mobile, then definitively you should use /64 for every PDP context, and clearly is NAT64. In this case, you don't need to take care about the CLAT part, just look at the /64 prefix for the logging. Make sure to talk about stateful NAT64 ... otherwise you create lot of confusion. You've some deployment hints at https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ Also, google for some of my IPv6-only tutorials (last RIPE meeting, APNIC meeting, etc., there are even videos of them). Regards, Jordi -Mensaje original- De: NANOG en nombre de Max Tulyev Fecha: domingo, 10 de febrero de 2019, 16:30 CC: NANOG Asunto: Re: IPv6 and forensic requests Hello Jordi, thank you, I will take a look on Jool! Exactly CLAT was the issue. First, I thought to provide a /128 to every mobile, and then do a static 6to4 to certain public IPv4. But it seems mobile need a /64, and it uses a lot of random IPv6 inside assigned /64, several addresses together at each time, CLAT uses the most of it (on Android). So direct translation 6->public4 is impossible. 10.02.19 15:51, JORDI PALET MARTINEZ пише: > Do you really mean 6to4 or NAT64? Totally different things ... > > If that's the case, I will suggest you go for Jool instead of Tayga. > > Also, if you want the customers are able to use old IPv4 apps and devices, NAT64 is not sufficient, you need also CLAT at the customer premises (so they can run 464XLAT). > > Regards, > Jordi > > > > -Mensaje original- > De: NANOG en nombre de Max Tulyev > Fecha: domingo, 10 de febrero de 2019, 14:26 > Para: NANOG > Asunto: IPv6 and forensic requests > > Hi All, > > we are implementing IPv6 only infrastructure. > > For IPv4 access, we using tayga for 6to4 translation and then CGN for NAT. > > There is a number of ways for Linux based NAT to store information for > future forensic requests (i.e. "who was it cracking that website?"). > > But what about 6to4 translators, as tayga? I believe there should be > well-known patches or solutions. The aim is to have what /64 (not even > /128) was translated to what IPv4 at the requested time. > > Is there any? > > > > > ** > 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 and forensic requests
You want this to log the bindings through the nat64 https://www.jool.mx/en/usr-flags-global.html#logging-bib Then you cross reference that with the /64 that is assigned to the UE in the CDR When doing lookups of this data, only look at the first 64 bits. That is all that matters and is unique to the UE. The last 64 bits in mobile is just noise from a Lawful Intercept and logging perspective. On Sun, Feb 10, 2019 at 7:29 AM Max Tulyev wrote: > Hello Jordi, > > thank you, I will take a look on > Exactly CLAT was the issue. > > First, I thought to provide a /128 to every mobile, and then do a static > 6to4 to certain public IPv4. But it seems mobile need a /64, and it uses > a lot of random IPv6 inside assigned /64, several addresses together at > each time, CLAT uses the most of it (on Android). So direct translation > 6->public4 is impossible. > > 10.02.19 15:51, JORDI PALET MARTINEZ пише: > > Do you really mean 6to4 or NAT64? Totally different things ... > > > > If that's the case, I will suggest you go for Jool instead of Tayga. > > > > Also, if you want the customers are able to use old IPv4 apps and > devices, NAT64 is not sufficient, you need also CLAT at the customer > premises (so they can run 464XLAT). > > > > Regards, > > Jordi > > > > > > > > -Mensaje original- > > De: NANOG en nombre de Max Tulyev < > max...@netassist.ua> > > Fecha: domingo, 10 de febrero de 2019, 14:26 > > Para: NANOG > > Asunto: IPv6 and forensic requests > > > > Hi All, > > > > we are implementing IPv6 only infrastructure. > > > > For IPv4 access, we using tayga for 6to4 translation and then CGN > for NAT. > > > > There is a number of ways for Linux based NAT to store information > for > > future forensic requests (i.e. "who was it cracking that website?"). > > > > But what about 6to4 translators, as tayga? I believe there should be > > well-known patches or solutions. The aim is to have what /64 (not > even > > /128) was translated to what IPv4 at the requested time. > > > > Is there any? > > > > > > > > > > ** > > 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 and forensic requests
Hello Jordi, thank you, I will take a look on Jool! Exactly CLAT was the issue. First, I thought to provide a /128 to every mobile, and then do a static 6to4 to certain public IPv4. But it seems mobile need a /64, and it uses a lot of random IPv6 inside assigned /64, several addresses together at each time, CLAT uses the most of it (on Android). So direct translation 6->public4 is impossible. 10.02.19 15:51, JORDI PALET MARTINEZ пише: Do you really mean 6to4 or NAT64? Totally different things ... If that's the case, I will suggest you go for Jool instead of Tayga. Also, if you want the customers are able to use old IPv4 apps and devices, NAT64 is not sufficient, you need also CLAT at the customer premises (so they can run 464XLAT). Regards, Jordi -Mensaje original- De: NANOG en nombre de Max Tulyev Fecha: domingo, 10 de febrero de 2019, 14:26 Para: NANOG Asunto: IPv6 and forensic requests Hi All, we are implementing IPv6 only infrastructure. For IPv4 access, we using tayga for 6to4 translation and then CGN for NAT. There is a number of ways for Linux based NAT to store information for future forensic requests (i.e. "who was it cracking that website?"). But what about 6to4 translators, as tayga? I believe there should be well-known patches or solutions. The aim is to have what /64 (not even /128) was translated to what IPv4 at the requested time. Is there any? ** 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 and forensic requests
Do you really mean 6to4 or NAT64? Totally different things ... If that's the case, I will suggest you go for Jool instead of Tayga. Also, if you want the customers are able to use old IPv4 apps and devices, NAT64 is not sufficient, you need also CLAT at the customer premises (so they can run 464XLAT). Regards, Jordi -Mensaje original- De: NANOG en nombre de Max Tulyev Fecha: domingo, 10 de febrero de 2019, 14:26 Para: NANOG Asunto: IPv6 and forensic requests Hi All, we are implementing IPv6 only infrastructure. For IPv4 access, we using tayga for 6to4 translation and then CGN for NAT. There is a number of ways for Linux based NAT to store information for future forensic requests (i.e. "who was it cracking that website?"). But what about 6to4 translators, as tayga? I believe there should be well-known patches or solutions. The aim is to have what /64 (not even /128) was translated to what IPv4 at the requested time. Is there any? ** 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.
