Le 29 juil. 2011 à 07:19, Qiong a écrit : > Hi, Remi, Dave, > > I'm not sure whether I get the point in Dave'd slide. Please correct me if > anything is wrong. > > In my understanding, the major problem in this failure mode would happen on > the downstream path, rather than the upstream one. A node which is attached > to an IPv6 network can determine whether to use shared-address system or not. > However, when the downstream IPv4 packet arrived at the network-side GW, it > can not tell whether the packet should be translated into shared-mode or > exclusive-mode. So it can not work unless network-side GW have know these > IPv4 addresses in advance for either mode.
In the downstream direction from the Internet, the stateless BR (no per customer state) maps the destination transport-address to an IPv6 destination address. Because this IPv6 destination address has an IID that no host recognizes (as discussed recently on the mailing list), the packet will be discarded. A Destination-Unreachable ICMPv6 message is then returned to the BR anycast address. The BR statelessly converts it into an IPv4 ICMP error message returned to the IPv4 source. If the path is direct from a CE of a 4V6 domain to another CE of the same domain, the ICMPv6 error message is returned to the source CE. This CE does the conversion to the right IPv4 ICMP message for the CE NAT44. Does this answer your concern? > Moreover, I think this issue would have distinct impact on stateless > solutions and stateful ones. For stateful ones, the states in AFTR have > already shown the binding information between IPv4 address/port set and IPv6 > address explicitly. While for stateless ones, these address mapping rules are > determined implicitly in algorithm. As a result, in order to reflect prefix > mapping information (discussed in multiple prefix threads), some more rules > would be needed to be introduced accordingly . > Of course, the number of rules would be significantly less than the number of > states . Yes, that's the point. The difference is between BR/AFTR's that have states _per customer prefix_ or just as many mapping rules as independent IPv4 prefixes. In addition, if several BR/AFTR's instances have to share their load for scalability, their per-customer states have to be identical. If per-customer states are dynamically updated this becomes complex. Last but not least, if there is one mapping rule per independent IPv4 prefix, direct CE-to-CE paths are possible (each CE knows all mapping rules). If BR/AFTR's have per-customer states, CE's don't know them. Direct CE-to-CE paths are impossible. Hope it helps. Kind regards, RD ... > > If a node is attached to an IPv6 network and ignores the static > shared-address system of this network, it won't be able to receive/accept > parameters of this-system mapping rule(s). > - It will therefore ignore that it could have used an exclusive port set of a > global IPv4 address. > - It will do nothing with its assigned address-and-port-set.
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
