Subject: [v6ops] no need to update RFC8026 in draft-ietf-v6ops-transition-ipv4aas

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 14 Jun 2018 18:21:43 +0200

Hi all,

After a long chat with the authors of RFC8026, we have found an alternative solution which avoids updating RFC8026 and also avoids requiring a new option code for 464XLAT, as there is already one that we can use, which is related to NAT64, so still can use RFC8026 for our original intend of prioritizing and managing the available mechanism from the operator network.

Consequently, we are working in a new version of draft-ietf-v6ops-transition-ipv4aas, which will be posted ASAP in v6ops.

Anyway, we had lot of fun in v6ops because this, and I think every comment has been very useful!

Thanks!

Regards,

Jordi

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
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.

---

From: Lencse Gábor <[email-masked]>
Date: Thu, 14 Jun 2018 22:15:16 +0200

Hello Jordi,

I am happy with this outcome. :-)

I have an idea: perhaps you could add a section about the pros and cons 
of each transition technology covered by the draft. (It could be helpful 
for the network operators when selecting the technology matching their 
need the best. However, I am not sure whether it is in the scope of this 
draft.)

What do you think of it?

Best regards,

Gábor

6/14/2018 6:21 PM keltezéssel, JORDI PALET MARTINEZ írta:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Fred Baker <[email-masked]>
Date: Thu, 14 Jun 2018 13:42:47 -0700

On Jun 14, 2018, at 1:15 PM, Lencse Gábor <[email-masked]> wrote:
> I have an idea: perhaps you could add a section about the pros and cons of each transition technology covered by the draft. (It could be helpful for the network operators when selecting the technology matching their need the best. However, I am not sure whether it is in the scope of this draft.)

It would be incredibly useful. That said, it often involves value judgements, which are essentially in the eye of the beholder.

We have had a recent thread regarding 464xlat and MAP-T. If I can say this without actually putting words into Lorenzo's mouth, his issues with translation in general are probably summarized in RFC 2993, and I would agree with him. The distinction between 464xlat and MAP-T you'll have to find in his emails; they are both services an ISP might deploy, and while they use the same tool (translation) they are not the same service. It seems to be generally agreed that MAP-T is more expensive to deploy than 464xlat; the question is what the extra expense buys, and whether someone agrees that the result is worth the cost.

So in your proposed section, I would have to ask Jordi to not only say "MAP-T costs more to deploy than 464xlat", but gives the argument that might lead someone to choose MAP-T.

And then we get to the large variety of other technologies, some of which presume an IPv4 core network and some an IPv6 core network (and none of which assume an MPLS core network carrying both kinds of traffic).

If you would like to write such a document, please be my guest, by all means. But I'm not going to expect Jordi to do all that in the coming two weeks...

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 14 Jun 2018 23:38:04 +0200

Not in scope, and I think that will make this draft an endless discussion.

Sometimes is not black and white, so I don't think the IETF can suggest one or other mechanism. Pros and cons maybe, but at the end many pros and cons need to be "balanced" in each network.

I've a presentation that do that and I even try to score each possible aspect of the transitions mechanisms, their impact in the network, etc., in an excel spreadsheet, but I always explicitly say "you really need to check this against your own case" ...

That said, I'm happy, once we are done with this draft, to start that work if the WG believe is useful.

Regards,

Jordi

-----Mensaje original-----

De: v6ops <[email-masked]> en nombre de Lencse Gábor <[email-masked]>

Fecha: jueves, 14 de junio de 2018, 22:16

Para: <[email-masked]>

Asunto: Re: [v6ops] no need to update RFC8026 in draft-ietf-v6ops-transition-ipv4aas

    Hello Jordi,

    draft.)

    What do you think of it?

    Best regards,

    Gábor

    v6ops mailing list

    [email-masked]

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 14 Jun 2018 23:49:39 +0200

Fred,

I'm easy to challenge ! But to be honest, prefer to concentrate the next two weeks in having people contributing to the actual document, and the NAT64 one.

In addition to that, I really thing mixing Gabor suggestion in this document will not be so useful at this stage and will break our original idea of making it as something to follow for CE vendors as RFC7084 (not operators).

But really, I'm happy to take that afterwards.

    v6ops mailing list

    [email-masked]

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 15 Jun 2018 00:16:55 +0200

Here is a link to that table (I just twitted it):

https://twitter.com/jordipalet/status/1007383535471222784

Is easy to understand how it works. Depending on each "feature impact or relevance" in your network you use red, orange or green (as a traffic light), and each color has a value (red 0, orange 0.5, green 1).

Of course, it is only an idea, and really depends on each network and how you value each "feature" (so the scoring could be adapted based on each network case).

ASAP I've a minute, I will try to add (if not already there) all the inputs that we have got in the list this week, but not just for MAP/464XLAT, for every mechanism.

To make it correctly in a draft, we will need to agree what it means each line. For example, "scalability" in what sense ? Is not so easy ... just recall when I wrote the draft about what it means "IPv6-only" ...

Regards,

Jordi

-----Mensaje original-----

De: v6ops <[email-masked]> en nombre de JORDI PALET MARTINEZ <jordi.palet=[email-masked]>

Fecha: jueves, 14 de junio de 2018, 23:50

Para: Fred Baker <[email-masked]>, Lencse Gábor <[email-masked]>

CC: <[email-masked]>

    

    Fred,

    

    

    

        v6ops mailing list

        [email-masked]

        

    

    IPv4 is over

    The IPv6 Company

    

    v6ops mailing list

    [email-masked]

---

From: Owen DeLong <[email-masked]>
Date: Fri, 15 Jun 2018 08:34:57 +0700

I agree with Jordi. Not in scope. 

This would make a fine white paper to publish somewhere, but IMHO, it’s certainly out of scope for this document, likely to be a fruitless flame war in this particular group. 

To be a useful white paper, I believe it should cover as many of the potentially useful (by the broadest definition of at least a few cases where the solution is in use exist) options and cover the facts, advantages, and trade offs of each one. It should not recommend any solution, but should provide a concise comparison allowing the reader to make an informed decision about what best fits their particular use case. 

While I think some members of this group could do an excellent job authoring such a paper, I do not believe it would likely survive the holy war that would ensue if it were a group project. 

Owen

Owen

> On Jun 15, 2018, at 04:38, JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:
>

---

From: Lencse Gábor <[email-masked]>
Date: Fri, 15 Jun 2018 14:23:57 +0200

Dear Fred,

Thank you very much for your invitation. I am willing to accept it, but 
I would like to clarify your expectations before saying 'yes'.

I have several questions.

1. Depth of the analysis

- Basic level: well-known advantages and disadvantages, similarly as 
people wrote about MAP-T/E and 464XLAT, but also about DS-Lite and lw4o6.
- Advanced level: basic level + security analysis using the methodology 
defined in [1] + performance analysis according to RFC 8219.

What depth do you recommend?

2. Method for getting the results and their publication

As for the information for the basic level, I would prepare a google 
docs table, fill in the information I have and send the link to the 
v6ops list asking contributions.
After commenting and discussing, I would compile it to an I-D.

Do you think that v6ops WG would finally agree to publish it as an RFC?

As for the information for the advanced level, I would work together 
with my students and PhD students, and publish our results first in 
academic papers and then include their most important lessons into the I-D.

What do you think of it?

3. Timeline

I think that I could put together the first table in a few weeks. The 
contribution of the v6ops list members and the discussion could be done 
in a few months and then I could compile the results into an I-D in a 
few weeks. Perhaps, it could be presented at IETF 103.

The further parts would require much more time and results could be 
included gradually in 1-2 years.

4. Scope

The smallest natural scope includes the technologies for IPv4AAS, that 
is: 464XLAT, DS-Lite, MAP-T/E and lw4o6.

IPv6 transition technologies for other carefully selected scenarios 
might also be included. E.g. I have significant amount of results in 
benchmarking DNS64 servers, having a testing tool [2], a well defined 
methodology [3] and ready to use results concerning the DNS64 
performance of BIND, PowerDNS and Unbound [4].
One of my PhD students is currently benchmarking some sateless NAT64 
implementations according the the dual DUT setup of RFC 8219 using an 
RFC 2544 compatible Tester. Another PhD student is currently working on 
a RFC 8219 compliant NAT64 tester program (using DPDK) to be able to 
perform single DUT setup NAT64 benchmarking tests.

Thus, the scope can be widened, if you would like to.

What do you think about my recommendations?

Best regards,

Gábor

References:

[1] G. Lencse and Y. Kadobayashi, "Methodology for the identification of 
potential security issues of different IPv6 transition technologies: 
Threat analysis of DNS64 and stateful NAT64", /Computers & Security/ 
(Elsevier), vol. 77, no. 1, pp. 397-411, August 1, 2018, DOI: 
10.1016/j.cose.2018.04.012

[2] G. Lencse, D. Bakai, "Design and implementation of a test program 
for benchmarking DNS64 servers", /IEICE Transactions on Communications/, 
vol. E100-B, no. 6. pp. 948-954, June 2017. DOI: 
10.1587/transcom.2016EBN0007

[3] G. Lencse, M. Georgescu, and Y. Kadobayashi, "Benchmarking 
Methodology for DNS64 Servers", /Computer Communications/ (Elsevier), 
vol. 109, no. 1, pp. 162-175, September 1, 2017, DOI: 
10.1016/j.comcom.2017.06.004

[4] G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 Implementations: 
Theory and Practice", /Computer Communications/ (Elsevier), vol. 127, 
no. 1, pp. 61-74, September 1, 2018, DOI: 10.1016/j.comcom.2018.05.005

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 15 Jun 2018 16:04:37 +0200

I’m not sure it makes sense something that is not published in, let’s say, maximum one year from now.

Anyway, I’m happy to help.

By the way, I got some private questions about this … The table that I’ve posted yesterday, was developed about 3 years ago, and I’ve not updated it since them. Actually from emails exchanged today, I discovered a couple of mistakes and also things that can be improved, so if needed I can update it as well.

Regards,

Jordi

De: v6ops <[email-masked]> en nombre de Lencse Gábor <[email-masked]>
Fecha: viernes, 15 de junio de 2018, 14:25
Para: Fred Baker <[email-masked]>
CC: <[email-masked]>
Asunto: [v6ops] Pros and Cons of IPv6 Transition Technologies for IPv4aaS -- Re: no need to update RFC8026 in draft-ietf-v6ops-transition-ipv4aas

Dear Fred,

Thank you very much for your invitation. I am willing to accept it, but I would like to clarify your expectations before saying 'yes'.

1. Depth of the analysis

- Basic level: well-known advantages and disadvantages, similarly as people wrote about MAP-T/E and 464XLAT, but also about DS-Lite and lw4o6.
- Advanced level: basic level + security analysis using the methodology defined in [1] + performance analysis according to RFC 8219.

As for the information for the basic level, I would prepare a google docs table, fill in the information I have and send the link to the v6ops list asking contributions.
After commenting and discussing, I would compile it to an I-D. 

As for the information for the advanced level, I would work together with my students and PhD students, and publish our results first in academic papers and then include their most important lessons into the I-D.

What do you think of it?

3. Timeline

I think that I could put together the first table in a few weeks. The contribution of the v6ops list members and the discussion could be done in a few months and then I could compile the results into an I-D in a few weeks. Perhaps, it could be presented at IETF 103.

The further parts would require much more time and results could be included gradually in 1-2 years.

4. Scope

The smallest natural scope includes the technologies for IPv4AAS, that is: 464XLAT, DS-Lite, MAP-T/E and lw4o6.

IPv6 transition technologies for other carefully selected scenarios might also be included. E.g. I have significant amount of results in benchmarking DNS64 servers, having a testing tool [2], a well defined methodology [3] and ready to use results concerning the DNS64 performance of BIND, PowerDNS and Unbound [4]. 
One of my PhD students is currently benchmarking some sateless NAT64 implementations according the the dual DUT setup of RFC 8219 using an RFC 2544 compatible Tester. Another PhD student is currently working on a RFC 8219 compliant NAT64 tester program (using DPDK) to be able to perform single DUT setup NAT64 benchmarking tests. 

Best regards,

Gábor

References:

[1] G. Lencse and Y. Kadobayashi, "Methodology for the identification of potential security issues of different IPv6 transition technologies: Threat analysis of DNS64 and stateful NAT64", Computers & Security (Elsevier), vol. 77, no. 1, pp. 397-411, August 1, 2018, DOI: 10.1016/j.cose.2018.04.012

[2] G. Lencse, D. Bakai, "Design and implementation of a test program for benchmarking DNS64 servers", IEICE Transactions on Communications, vol. E100-B, no. 6. pp. 948-954, June 2017. DOI: 10.1587/transcom.2016EBN0007

[3] G. Lencse, M. Georgescu, and Y. Kadobayashi, "Benchmarking Methodology for DNS64 Servers", Computer Communications (Elsevier), vol. 109, no. 1, pp. 162-175, September 1, 2017, DOI: 10.1016/j.comcom.2017.06.004

[4] G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 Implementations: Theory and Practice", Computer Communications (Elsevier), vol. 127, no. 1, pp. 61-74, September 1, 2018, DOI: 10.1016/j.comcom.2018.05.005

 

 

_______________________________________________ v6ops mailing list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops

---

From: Lee Howard <[email-masked]>
Date: Mon, 18 Jun 2018 10:38:38 -0400

Apparently I'm a week late on this thread. Sorry.

I think an internet-draft in this case would be useful for reflecting 
the current best knowledge about the technologies. Even if it takes two 
years or more to publish, a draft is useful to collect  and summarize 
the detailed academic papers being published, and the structure of 
writing the draft will help point out areas where further research is 
needed.

I'm also interested in supporting this work, up to and including working 
with your students,  providing my own test results, and/or co-authoring.

Lee

On 06/15/2018 10:04 AM, JORDI PALET MARTINEZ wrote:
> By the way, I got some private questions about this … The table that 
> I’ve posted yesterday, was developed about 3 years ago, and I’ve not 
> updated it since them. Actually from emails exchanged today, I 
> discovered a couple of mistakes and also things that can be improved, 
> so if needed I can update it as well.
>
>
> Regards,
>
> Jordi
>
> *De: *v6ops <[email-masked]> en nombre de Lencse Gábor 
> <[email-masked]>
> *Fecha: *viernes, 15 de junio de 2018, 14:25
> *Para: *Fred Baker <[email-masked]>
> *CC: *<[email-masked]>
> *Asunto: *[v6ops] Pros and Cons of IPv6 Transition Technologies for 
> IPv4aaS -- Re: no need to update RFC8026 in 
> draft-ietf-v6ops-transition-ipv4aas
>
> Dear Fred,
>
> Thank you very much for your invitation. I am willing to accept it, 
> but I would like to clarify your expectations before saying 'yes'.
>
> - Advanced level: basic level + security analysis using the 
> methodology defined in [1] + performance analysis according to RFC 8219.
>
> contribution of the v6ops list members and the discussion could be 
> done in a few months and then I could compile the results into an I-D 
> in a few weeks. Perhaps, it could be presented at IETF 103.
>
> RFC 2544 compatible Tester. Another PhD student is currently working 
> on a RFC 8219 compliant NAT64 tester program (using DPDK) to be able 
> to perform single DUT setup NAT64 benchmarking tests.
>
> [1] G. Lencse and Y. Kadobayashi, "Methodology for the identification 
> of potential security issues of different IPv6 transition 
> technologies: Threat analysis of DNS64 and stateful NAT64", /Computers 
> & Security/ (Elsevier), vol. 77, no. 1, pp. 397-411, August 1, 2018, 
> DOI: 10.1016/j.cose.2018.04.012
>
> for benchmarking DNS64 servers", /IEICE Transactions on 
> Communications/, vol. E100-B, no. 6. pp. 948-954, June 2017. DOI: 
>     On Jun 14, 2018, at 1:15 PM, Lencse Gábor<[email-masked]> <mailto:[email-masked]>  wrote:
>
> _______________________________________________ v6ops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
>
> 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.
>
>
>

---

From: Lencse Gábor <[email-masked]>
Date: Tue, 19 Jun 2018 09:08:14 +0200

Dear Lee,

Thank you very much for offering your help and participation. I have 
decided to write the draft and I invite you to be a co-author.

Are there some other people, who would like to join us?

I plan to put together a table with the information extracted from past 
e-mails on the list and send it to Lee (and possibly other participants) 
first, and send the Google docs URL to the list after we agreed on its 
initial content.

Best regards,

Gábor

6/18/2018 4:38 PM keltezéssel, Lee Howard írta:
> the current best knowledge about the technologies. Even if it takes 
> two years or more to publish, a draft is useful to collect  and 
> summarize the detailed academic papers being published, and the 
> structure of writing the draft will help point out areas where further 
> research is needed.
>
> I'm also interested in supporting this work, up to and including 
> working with your students,  providing my own test results, and/or 
> co-authoring.
>
> Lee
>
>
>> The smallest natural scope includes the technologies for IPv4AAS, 
>> that is: 464XLAT, DS-Lite, MAP-T/E and lw4o6.
>>
>> technologies: Threat analysis of DNS64 and stateful NAT64", 
>> /Computers & Security/ (Elsevier), vol. 77, no. 1, pp. 397-411, 
>> August 1, 2018, DOI: 10.1016/j.cose.2018.04.012
>>
>> [4] G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 
>> Implementations: Theory and Practice", /Computer Communications/ 
>> (Elsevier), vol. 127, no. 1, pp. 61-74, September 1, 2018, DOI: 
>> 10.1016/j.comcom.2018.05.005
>>
>> authorized disclosure, copying, distribution or use of the contents 
>> of this information, even if partially, including attached files, is

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 19 Jun 2018 09:28:42 +0200

Hi Lenser,

Yeah, I will be happy to join as well.

Regards,

Jordi

De: v6ops <[email-masked]> en nombre de Lencse Gábor <[email-masked]>
Fecha: martes, 19 de junio de 2018, 9:09
Para: <[email-masked]>
Asunto: [v6ops] "BoF" for I-D -- Re: Pros and Cons of IPv6 Transition Technologies for IPv4aaS -- Re: no need to update RFC8026 in draft-ietf-v6ops-transition-ipv4aas

Dear Lee,

Thank you very much for offering your help and participation. I have decided to write the draft and I invite you to be a co-author.

I plan to put together a table with the information extracted from past e-mails on the list and send it to Lee (and possibly other participants) first, and send the Google docs URL to the list after we agreed on its initial content.

Best regards,

Gábor

I think an internet-draft in this case would be useful for reflecting the current best knowledge about the technologies. Even if it takes two years or more to publish, a draft is useful to collect  and summarize the detailed academic papers being published, and the structure of writing the draft will help point out areas where further research is needed.

I'm also interested in supporting this work, up to and including working with your students,  providing my own test results, and/or co-authoring.

Lee

Regards,

Jordi

Dear Fred,

1. Depth of the analysis

What do you think of it?

3. Timeline

4. Scope

Best regards,

Gábor

References:

---

From: Richard Patterson <[email-masked]>
Date: Tue, 19 Jun 2018 09:29:14 +0100

Hi Lencse,

I'd be happy to help also.

-Richard

---

From: Alejandro D'Egidio <[email-masked]>
Date: Thu, 21 Jun 2018 12:05:18 -0300 (ART)

Hi Lencse,
  If is possible, I would like to help.

Regards,

ALEJANDRO D'EGIDIO 
Jefe de Ingeniería de Backbone 
F: +54 11 3977 1025  | M: +54 911 5794 1589 
Lavardén 157. Piso 3. CABA (C1437FBC)

----- Mensaje original -----
De: "Richard Patterson" <[email-masked]>
Para: [email-masked]
CC: "[email-masked] list" <[email-masked]>
Enviados: Martes, 19 de Junio 2018 5:29:14
Asunto: Re: [v6ops] "BoF" for I-D -- Re: Pros and Cons of IPv6 Transition Technologies for IPv4aaS -- Re: no need to update RFC8026 in draft-ietf-v6ops-transition-ipv4aas

Hi Lencse,

-Richard