2012/4/12 Behcet Sarikaya <[email protected]> > On Tue, Apr 10, 2012 at 10:29 PM, Maoke <[email protected]> wrote: > > hi Yiu, > > > > sorry but i just found i missed a technical issue you left in this > message. > > > > 2012/4/9 Lee, Yiu <[email protected]> > > > >> > >> on the other hand, 4rd-u makes a tight coupling between the address > >> format > >> and its own header mapping mechanism. this makes an operator unable > to > >> have > >> different choices of transition mechanism as long as it chooses > 4rd-u. > >> if > >> you concern the choice of IPv6 transition mechanism, i do recommend > >> MAP, as > >> either encapsulation or translation is operatable with MAP > >> address/port > >> mapping without difficulty. > >> > >> [YL] Sorry for my lack of knowledge. Please explain how MAP isn't > coupling > >> address format and header mapping? > > > > > > tight coupling here, i mean, that 4rd-u header mapping mechanism > sometimes > > depends on features of the address format, like the CNP and the V-octet. > for > > example, it removes the L4 checksum adjustment, this makes the whole > system > > MUST following the addressing with CNP. > > > > for the MAP, things are different. boxes are implemented with existing > > header processing modules but only need to add MAP address mapping module > > into them. once the operator deploys MAP following its addressing plan > > paradigm (we are still working on a better guidance for this in the MAP > > deployment draft), the operator can choose either MAP-T or MAP-E for the > > header mapping without the need of changing their addressing plan. if the > > operator find translation is suitable for this part after a certain > period > > of practice on encapsulation, it can switch the mode by informing the CE > to > > change the mode of working (surely sometimes such an action of informing > is > > not easy in practice for, e.g., the home CE subscribers but it is > feasible > > for enterprise networking). another example of de-coupling is translation > > approach: RFC6052 defines a stateless address mapping while RFC6145 > defines > > the header processing which is usable for both stateless and stateful > > solutions, both 1:1 case for non-renumbering transition and residual > > deployment of MAP. > > > > implementation does also benefit from the de-coupling. the RFC6145 > > translation module can directly work with address mapping module of MAP > or > > RFC6052. the MAP address module can work with header processing module of > > RFC2473 (for MAP-E) or translation module of RFC6145 (for MAP-T). > > > > it doesn't mean the tight coupling doesn't work. like the Burton > snowboard, > > it works fantastically with its own system of bindings, not > interchangable > > for other brands ;-) however, in most of time, we really think > > interchangability, supported by loose coupling, is preferred. > > > > > > I fail to understand why there is so much hype around these standards, > > 6145 is the good old SIIT > 6052 defines NAT64 prefixes. >
2765 is the old SIIT. 6145 changes it to a certain extent. the above is just my understanding on the content separation of 6052, 6144, 6145, 6146. what i said was only one point -- "decoupling". and i like these standards having this. i don't see where there is "so much". as to the "hype", well, no comment. out of technical discussion. ;-) - maoke > > Behcet >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
