Fred, Margaret, Thanks to Fred for addressing my concern. Here are further explanations and, unless I am mistaken, what I hope you will recognize as very constructive suggestions.
Le 14 déc. 2010 à 06:49, Fred Baker a écrit : > If you would like, I can send you the code I tested this with. Not necessary. Mathematical reasoning should be sufficient, and see the good news below. > ... > I think you'll find that if you do the substitution, when the word you are > updating starts with 0xFFFF, you can't predictably get it back to 0xFFFF. Any > value from 0x0000 to 0xFFFE is perfectly reversible, though. I'll let you > work out the reason why. 1. The point was not that the algorithm isn't reversible if the *word to be updated* is 0xFFFF (remember that, as recalled in the appendix below, I was at the origin of the exclusion of 0xFFFF in the subnet field in the first draft!). It was, and remains, the LACK OF JUSTIFICATION for replacing 0xFFFF by 0x0000 *in the updated word*: - Let's take the /48 case - Let A be the 16-bit word to be updated (bits 48..63 of the internal prefix) - Let B be the computed adjustment - Let C be the updated 16-bit word - Let's assume, for example, that A=0xFF00 and B=0x00FF, two legitimate values that give A+B=0xFFFF Then, why to take C=0x0000 instead of C=A+B (noting that, with C=0xFFFF, one obtains A=C-B=0x00FF). 2. Now, a first good news: Having worked more on the mathematics of the complete algorithm, I can now say say that *I agree that the proposed algorithm CAN work*. It remains that explanations are still missing and that it is MORE COMPLEX than needed. In my understanding, the reason why the (unnecessary) replacement of C=0xFFFF by C=0x0000 isn't harmful is that: - the only case where A+B=0x0000 is when both A=0x0000 and B=0x0000 (all other computation whose result is 0 in one's complement give 0xFFFF) - in this case, the replacement of A=0xFFFF by A=0x0000 in the reverse computation gives the right result. Yet, unless I miss something,the replacement of C=0xFFFF by C=0x0000 can be removed from the specification. 3. And now, an even better good news: In the algorithm for prefixes longer than /48, there is a search for the first 16-bit word of the IID that isn't 0xFFFF. But in the case of ULAs, which are only local addresses, the first such word is never 0xFFFF (RFC4291 imposes that bit 7 of IIDs be =0). Thus, bits 64..79 can be the ONLY ONES to be used. There is no need for a search in other bits. And now, guess what: if this same field is used in the /48 case, the EXCLUSION of the 0xFFFF subnet ID is NO LONGER NEEDED. This is IMHO an important operational improvement at no cost. > I'll post a new version tomorrow. I got some comments from Ralph Droms, which > I will edit in, and I'll put the code for my test in an appendix. Well, I have other comments, but a conclusion on the above would be appreciated before going on. Regards, RD APPENDIX > De : Margaret Wasserman <[email protected]> > Date : 25 novembre 2008 16:52:55 HNEC > À : Rémi Després <[email protected]> > Cc : Fred Baker <[email protected]>, Behave WG <[email protected]> > Objet : Rép : [BEHAVE] Non reversibility of address mappings in the "NAT66" > draft > > > Hi Remi, > > I ran some numbers this morning, and you are right. > > If the _original_ value of the 16-bit checksum correction field is 0x0000, it > will be restored to 0xFFFF, which is wrong. The checksum correction works > fine (as Fred's tests have proven), but the restoration of the value doesn't > work properly. It can be made to work properly for either 0x0000 or 0xFFFF, > but I haven' t figured out a way to make it work right for both values as the > information to distinguish between them is lost. > > There are three approaches we can take to fix this > ... _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
