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. 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 . Best regards Qiong Sun > 2. > Unless I misinterpreted, you asked about the failure mode of a host that > isn't part of a shared IPv4 address system and is attached to such a system. > > Assuming that, in the context of the discussion, this implicitly referred > to a "static" shared-address system, I don't see which problem there would > be: > - 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. > > Is this OK, or did you have in mind something more complicated which you > could detail? > > > Kind regards, > RD > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
