Le 29 oct. 2010 à 18:52, Margaret Wasserman a écrit : > > Hi Remi, > > Thanks for the feedback. > > On Oct 29, 2010, at 12:46 PM, Rémi Després wrote: >> 1. Sec 8, 2nd paragraph >> Isn't it bits 49-64 instead of 34-48? > > Yes, this will be fixed. Actually, it is 33-48.
I do agree with your last e-mail on the subject: the right value is 48-63! >> >> 2. Sec 11, last paragraph, (rightly) has "NAT66 devices with more than one >> internal interface SHOULD assign a (non-0xFFFF) subnet" >> This isn't sufficient. >> It must also apply to networks that have several NAT66 devices with a single >> interface in each. >> Besides, an explanation of why it is so should IMHO be added. > > It is not necessarily the case that a NAT66 device will be aware that there > are other NAT66 devices attached to the same network. With the spec as is, 0xFFFF must be avoided in bits 48-63 of ALL internal addresses it they are subject to stateless NAT66. (In the inbound direction, where this field should be restored to 0xFFFF, it is restored to 0x0000. Due to "If the resulting value is 0xFFFF, it is changed to 0x0000", the mapping isn't completely 1:1. > It is up to the network administrators to determine if multiple NAT66 > devices on a network will be configured to use the same internal prefix or > different ones. > > Why do you think special wording is needed for this case? The current sentence suggests that, if each CPE of a multi-CPE site has only one interface, each one MAY have 0xFFFF in bits 48-63. In my understanding, this is wrong. Regards, RD _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
