Le 6 déc. 2010 à 20:03, Fred Baker a écrit : > ... > ftp://ftpeng.cisco.com/fred/nat66/draft-mrw-nat66-00-01-diff.html > ... I'd appreciate comments on it from this list.
1. In a mail of Oct. 31 to yourself with copies to Margaret and to the list, I wrote: <<< Your draft-mrw-nat66-00 says: (a) "If the resulting value is 0xFFFF, it is changed to 0x0000" (sec. 8, second paragraph) ... I found in the draft no technical justification for these rules, so that: - The reason for (a) remains obscure to me. ... until you would provide TECHNICAL REASONS showing how (a) ..., or some revised rules, would ensure address-mapping reversibility, it is legitimate to doubt, as I do, that your new proposal works in all identified cases. >>> I didn't receive any answer yet, and the new draft hasn't changed on this point. 2. Here is, then, a further explanation on the problem I see: - If a translation includes a last step that forces a single final result for two different intermediate results, *it cannot be reversible*. - Sec. 8 says "If the resulting value is 0xFFFF, it is changed to 0x0000", this applying to both translation directions as confirmed in the example. - Thus, two different original values of the 16-bit modified 16-bit word can, in the outgoing translation, give the same final value 0x0000. There is then no way in the reverse direction to determine which was the original value. 3. For /48 prefixes, *the problem can easily be fixed*. It is sufficient to delete the change from 0xFFFF to 0x0000 in the outgoing translation. (Concerning the incoming translation, an example should show why this change is actually needed. If it wouldn't, discarding packets addressed to the forbidden 0xFFFF subnet would be better than sending them to the 0x0000 subnet. The example would show that the specified algorithm can translate an original 0x0000 into a value that, when translated back, gives 0xFFFF.) 4. For longer prefixes, I found *NO SIMPLE SOLUTION*. If there is enough pressure to get a solution also for this case, a convincing proof that the proposed solution works should IMHO be provided. 5. I have many other comments, but this one is the important enough to deserve an independent answer. Regards, RD I wrote: > > The big changes are: > - Change the acronym "NAT66" to "NPTv6", so people don't read > "NAT" and MEGO. > - Change the term used to refer to the function from "NAT66 > device" to "NPTv6 Translator". It's not a "device" function, > it's a function that is applied between two interfaces. Consider > a router with two upstreams and two legs in the local network; > it will not translate between the local legs, but will translate > to and from each upstream, and be configured differently for > each of the two ISPs. > - Comment specifically on the security aspects. > - Comment specifically on the application issues raised on this > list. > - Comment specifically on multihoming, load-sharing, and asymmetric > routing. > - Spell out the hairpinning requirement and its implications. > - Spell out the service provider side of Address Independence; > -00 focuses on the edge's view > - Detail the algorithm in a manner clearer to the implementor > (I think) > - Spell out the case for GSE-style DMZs between the edge and the > transit network, which is about the implications for the global > routing table. > - Refer to draft-ietf-v6ops-cpe-simple-security > > _______________________________________________ > nat66 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nat66 _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
