Remi, >>> 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)
ah, OK I see. stateless, managed, tunnels to a host behind a non IPv6 capable CPE. I missed the Teredo reference in Brian's mail. I don't quite understand how these types of tunnels can be provisioned in a "managed" way though?? cheers, Ole _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
