Hi Remi,
On Oct 30, 2010, at 2:55 AM, Rémi Després wrote:
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.
The only addresses that are translated by the NAT66 box are the local
addresses: source address for outbound packets and destination for
inbound packets. The specification already states that sites that
deploy NAT66 may not use a subnet with 0xFFFF in bits 48-63. This
applies to both the internal and global prefixes.
BTW, this only applies if the site is using a prefix length of /48 or
shorter. If a longer prefix is used, any subnet value can be used
because the correction is done in the IID. I should check and make
sure that the spec is clear on that.
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.
I'll read over the text and see if I can make it clearer. In a case
where NAT66 is used with a prefix length of /48 or shorter (even just
one box with one interface), subnets ending in 0xFFFF (all ones in
bits 48-63) can't be used. Network administrators will need to make
sure that is true, as par of installing NAT66.
Margaret
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
