Dear Sheng, This is to confirm on the WG list what I discussed with you concerning 4rd and NAT64+.
1. Adaptation of the 4rd draft to 6man precluding IID-range reservations, appears to have been incomplete: - Without a 4rd IID-range reservation, a NAT64+ can no longer distinguish 4rd-capable CEs from other hosts or CEs on the sole basis that their IPv6 addresses contain the 4rd tag. (A host behind a non-4rd CPE MAY be configured with such an address, e.g. by manual configuration ignoring the u/g bit meaning of RFC4291.) - The following sentence of R-11 is therefore no longer applicable: "The NAT64+, being NAT64 conforming [RFC6146], uses (b) as source addresses that depend on IPv4 sources. It finds in its binding information base addresses conforming to (a). Finding the 4rd tag in them, it uses 4rd tunneling rather than IPv4 to IPv6 translation." 2. The following is an example of how to restore full consistency of the specification: (1) Delete the above sentence. (2) Add a new R-xx saying: "Each NAT64+ MUST accept IPv6 packets whose destination addresses contain its NAT64+ prefix, necessarily a /64, followed by the 4rd tag. It MUST note, e.g. in its Binding Information Base, which IPv6/IPv4 bindings have been created with such 4rd destination addresses (as opposed to destination addresses containing the "u" octet of [RFC6052]). In the IPv4 to IPv6 direction, it MUST use IPv6 source addresses containing the 4rd tag, and conforming to of Figure 6 (b), for all bindings noted as created with 4rd destination addresses. 3. This contribution is intended to be limited to its technical substance, without view on how to best handle the issue at this point (before or after WGLC? With which precise text? ...). What will be decided in the WG should be fine AFAIAC. Thank you and best regards, RD _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
