Le 22 mars 2011 à 08:47, Ole Troan a écrit : > Brian, > >> It seems that a real world problem case is not covered by this >> update: tunneling v6 over v4 when there is a legacy CPE NAT in the way, >> in an ISP-managed way (unlike Teredo). At the moment this is a well >> known but orphaned problem, which will remain with us until the last >> NAT44-only consumer CPE device has gone. >> >> It's certainly the case that this scenario doesn't quite match >> RFC 4925 and doesn't need to "support all combinations of IP versions >> over one other." However, that is just a matter of charter wordsmithing. >> >> Nit: there's a reference to NAT-PT; maybe it should be NAT64 these days. > > that was the problem one set out to solve with RFC5571 (L2TP). > what's missing from that solution?
Nothing that I know for its solution space, but this solution space is only stateful and hub-an-spoke. In particular, two host in the same customer site communicate in IPv6 via the L2TP Network server, which is an important functional limitation. As you know, as co-author of RFC 5969 on 6rd, a complementary and useful solution space is that of stateless solutions. In this pace, we all know that 6rd isn't sufficient to rapidly deploy IPv6 where there are legacy CPE's. A solution for this complementary scenario is therefore desirable. As it happens to be also possible, as shown in the 6a44 proposal, a work item on it has to be identified. Softwire, where 6rd has been in scope, seems the logical place to finalize this complementary solution. (It is also the logical place to finalize the 4rd solution, but this wasn't your question and is a different discussion) Regards, RD > > cheers, > Ole > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
