Hi all, 1. Being active in the IETF community has been overall enjoyable but, for various personal reasons including financial, I will no longer contribute as much as before on v4/v6 transition solutions (6rd, 4rd, 6a44).
This is the reason why I didn't pursue authorship responsibility for the last softwire-4rd draft (thanks to Tetsuya Murakami and Ole Troan for having taken over). Although not going to Quebec, I hope that my remaining email contributions, including this one, will be taken in consideration to optimize the 4v6 end result. 2. Both the proposed translation-based solution (draft-murakami-softwire-4v6-translation) and the proposed tunnel-based solution (draft-murakami-softwire-4rd) use the v4v6 address mapping algorithm, that of 4rd. It would therefore be advantageous to have an autonomous I-D on the 4rd address mapping, and two I-D's pointing to it (for the translation-based and for the tunnel-based solution). Proposed respective acronyms: "4V6T" (translation) and "4V6E" (E for Encapsulation). In the analysis of stateless 4via6 solutions, initiated in draft-dec-stateless-4v6, issues related to the following specifications could then be better isolated: 4V6 in general, 4rd, 4V6T, 4V6E. Kind regards, RD _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
