Hi, Remi, Thanks for your email and contribution. As I have confirmed privately, I agree with your comment and have recorded your suggested modification for next update. They will be addressed with other comments we received.
Best regards, Sheng >-----Original Message----- >From: Rémi Després [mailto:[email protected]] >Sent: Tuesday, May 14, 2013 10:04 PM >To: Sheng Jiang >Cc: Softwires WG >Subject: 4rd update concerning NAT64+ > >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
