Le 15 déc. 2010 à 01:18, Fred Baker a écrit : > I disagree that a ULA cannot use a privacy address. It's an RFC 4291 prefix, > end of discussion, and RFC 4291 addresses can use EUI-64 or privacy addresses. Oops. Fortunately, I didn't write that "ULA cannot use a privacy address", because I never believed that! But I see how you derived such an assumption: the reason I gave for IIDs of local addresses never start with 0xFFFF was incomplete. The complete reason is that *bit 7 OR bit 6 is 0* in these addresses. (Bit 7, the "g" bit, is 0 in modified EUI64 addresses; bit 6, the "inverted "u" bit, is 0 in privacy addresses.)
> Sigh. Regarding suppression of 0xFFFF... This was a point on which the behave > working group had a long discussion and decided what they wanted to see. > There are two ways to do it, but one has to pick one or the other for > interoperability. Well understood, and agreed. > I have some code I used to verify the algorithm; it's attached. I just sat > down and rewrote it to correlate it exactly to the draft - which I have just > reposted to pick up some comments that Ralph Droms made. I am also including > this code in an appendix. > > The program has one option: whether or not the 0xFFFF suppression to 0x0000 > is implemented. If the option is zero (false), I do NOT suppress 0xFFFF. If > the option is 1 (true), I suppress 0xFFFF by overwriting with zero. > > I only test the /48 case; the math is the same in the longer prefix cases, > although the field is different. Whether I suppress 0xFFFF or not, I check > every conceivable subnet number, from 0..FFFF. > > Please read the attached code and tell me what bugs I have in it. I didn't say there is a bug in your code? On the contrary, I said in my mail that, although the current design was more complex than needed, "the proposed algorithm CAN work". But here again my explanation was incomplete so that your interpretation became legitimate. The intent was to discuss address modification *ONLY in the outgoing direction*. The sentence that made it clear disappeared during the editing process :-(. > What the code is telling me is that 0xFFFF suppression is not necessary, but > having a subnet of one or the other representation of zero is a bad idea - > and which is a bad idea depends on whether I do or don't suppress 0xFFFF. > > [stealth-10-32-244-221:~] fred% a.out 0 > outer->inner different: fd01:203:405:ffff:2:3:4:5 vs fd01:203:405:0:2:3:4:5 > > If we turn suppression off, a subnet number of 0x0000 converts to 0xFFFF in > the destination address returning. > It does this because it added the adjustment in one direction and subtracted > it in the other direction, and in one's complement arithmetic, where x-x = x > + (-x) = zero, it results in the negative zero. > > [stealth-10-32-244-221:~] fred% a.out 1 > outer->inner different: fd01:203:405:0:2:3:4:5 vs fd01:203:405:ffff:2:3:4:5 > > If we turn suppression on, a subnet number of 0xFFFF converts to 0x0000 in > the destination address returning. > > Think about it. For simplicity, let's calculate x-x in a two bit one's > complement number field. > > 00-00 = 00 + (-00) = 00 + 11 = 11 > 01-01 = 01 + (-01) = 01 + 10 = 11 > 10-10 = 10 + (-10) = 10 + 01 = 11 > 11-11 = 11 + (-11) = 11 + 00 = 11 > > So, if I don't suppress 0xFFFF, a subnet number of 0 comes back as 0xFFFF, > and if I do, the suppression makes a subnet number of 0xFFFF come back as > zero. I can or I can't have the suppression, but I can't have a subnet number > of one of the two representations of zero. By convention, in the Internet, > per RFC 1071 we suppress 0xFFFF, and that means that I forbid the use of > subnet 0xFFFF as well. > > <nat66.c> Agreed on all of this but, as said above, this is needed only in the incoming direction. All my apologies for the two incomplete explanations I gave. With the two clarifications-corrections above, I believe that the substantial simplification I suggest keeps its value. Regards, RD > > On Dec 14, 2010, at 6:45 AM, Rémi Després wrote: > >> 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
