Hi Remi, Thanks. I think your solution would work, but it still get ICMP Unreachable message rather than normal communication packet.
Ok, I will keep silent and let's wait for Dave's answer :) On Fri, Jul 29, 2011 at 3:42 PM, Rémi Després <[email protected]>wrote: > > 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
