On Dec 15, 2010, at 7:17 AM, Christian Huitema wrote: > Fred, > > Your program does not test for collision of the output, i.e. 2 inputs giving > the same output. > > -- Christian Huitema
Good catch. Thanks. See attached. The output is the same.
nat66.c
Description: Binary data
> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Fred Baker > Sent: Tuesday, December 14, 2010 4:18 PM > To: Rémi Després > Cc: Margaret Wasserman; NAT66 HappyFunBall > Subject: Re: [nat66] Constructive suggestions > > 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. > > 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. > > 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. > > 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 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
