Hi Nejc, Thanks for this contribution. +1 to have it pursued.
Maybe it would be better to only cover specifications for which drafts are available. (I found the two "DSlite?" columns confusing, with no document to check their validity.) Also, some of us are currently working on separating the 4rd "stateless address mapping" from its possible application to various encapsulation and translation mechanisms. When done, hopefully soon, this could influence the way to structure your comparison table. Regards, RD Le 11 août 2011 à 22:00, Nejc Škoberne a écrit : > Hello all, > > I am working on a trade-off analysis of IPv4 address sharing mechanisms. I am > replying to Remi's e-mail (sent before I subscribed to the list): > >> I therefore worked out a way to present the range of solutions to be >> compared, >> with the following taken in consideration: >> - The stateless/stateful IPv4 across IPv6 comparison isn't limited to IPv4 >> shared addresses (applies also to exclusive IPv4 customer addresses). >> - If there is, in BR/AFBR's, no Customer state (i.e. no states referring to >> individual IPv6 prefixes), there can't be per-transport-connection state >> either. >> - CE-CE direct paths are possible only if IPv4/IPv6 mappings of BR/AFBR's >> don't >> depend on Customer state. >> >> The proposed document structure is as follows, with pros and cons for each >> section: >> a) Stateful per transport connection (and also stateful per customer IPv6 >> prefix) >> e.g. DS-lite with CGN >> b) Stateful per customer IPv6 prefix (but Stateless per transport connection) >> e.g. draft-cui-softwire-host-4over6-06 >> c) Stateless per customer IPv6 prefix (and also stateless per transport >> connection) >> - Hub-an-spoke >> TBD >> - Direct CE-CE paths (mesh) >> . Encapsulation based >> e.g. draft-murakami-softwire-4rd-00 alias >> . Translation based >> e.g. draft-murakami-softwire-4v6-translation-00 > > I think we really need such a comparison document. As a newcomer I spent a lot > of time digging up all the scattered documents here and it wasn't easy grasp > the > "big picture" of what has been proposed. I think we also need a trade-off > analysis > document, which I am writing at the moment. > > Anyway, I am not sure I agree with the structure suggested. I think we should > try > to be even more general and try to abstract all packet manipulations. I have > prepared > a table which tries to document all so-far implemented combinations (IPv4 > address sharing > mechanisms + 4via6 mechanisms, the intersection includes all but NAT444, > which is > only IPv4 address sharing mechanism and Public 4over6 which is only a 4via6 > mechanism). > It would be useful to know if any of the missing combinations might be useful > in > practice as well, I hope this table will help in determining that. > > I will be very happy to hear any comments on the comparison. It's only a > 1-page table. > > The PDF document: http://nejc.skoberne.net/transfer/mechanisms.pdf > > Thanks, > Nejc > > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
