Peng, > Now there are actually 3 directions for IPv4-over-IPv6 mechanisms, > they have respective application scenarios, pros and cons. > 1)stateless, 4rd, MAP > 2)per-flow stateful: DS-Lite > 3)per-user stateful: public 4over6, lightweight 4over6 > As Ole said, the problem is that, do we want serveral simple > mechanisms, or one super-compatible mechanism with different modes. > > Now Given that a) the WG has accomplished DS-lite; b)MAP follows the > stateless motivation all along the way; c)The signifcant changes to > make MAP super-compatible, I vote for we define the third type, > per-user stateful mechanisms independently.
actually there are no significant changes to the MAP specification, the per-user stateful mechanism is just intrinsically supported by MAP. it is a corner case, and it would be more work in the specification to "ban" this operational mode, than to support it. btw, one thing that appears most complicated is provisioning; currently it looks like L4over6 suggests using 2 DHCP sessions and 3 DHCP options to get provisioned. firstly a RFC6334 exchange to get the DS-lite tunnel up, then a DHCPv6 option for the DHCPv4 server address, and then a DHCPv4 exchange to get the IPv4 address, and then a new DHCPv4 option to get the port set. that seems to me to be quite a few moving parts, and quiet a few corner cases to be specified when one or more of the above fails. in MAP you do all of that with one single DHCPv6 option... cheers, Ole _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
