>> >>I read your 4rd draft. As far as I know, the current 4rd draft supports 3 >> models: >> >> 1. An IPv4 prefix >> 2. Full IPv4 address (No port sharing) >> 3. IPv4 address and a range of ports >> >> So case 2 is equal to 4over6. Is my understanding right? > >yes, the 'service' provided should be the same. >I presume 4over6 also could do 1? Currently, we only focus on 2 without 1. Because if we use DHCPv4 over IPv6 tunnel, DHCPv4 doesnot support prefix assignment, right? > >the main differences between 4over6 and 4rd for case 2, would be how it >is provisioned and that 4over6 wouldn't have any dependency between the >tunnel endpoint addresses and the payload addresses. >obviously 4rd could be made less dependent of that too, by assigning >specific IPv6 addresses for the mapping, independent of the delegated >IPv6 prefix used within the end user site. doing that you really keep >mapping state in the RIB. but that's definitely one deployment model of >4rd. Even for 2, the use cases are different between 4over6 and 4rd because of the independency of IPv4/IPv6 addresses. For example, 4over6 can assign the public IPv4 addresses to a few high-priority hosts distributed in a large-scale network withOUT changing the local network devices or the current policy of IPv6 address assignment. So we don't need the cooperation with the local IPv6 address assignment. That's quite important for our CERNET2.
Yong > >cheers, >Ole > >>>> Absolutely. L2TP tunnels are widely use in many areas including >>>>4over6. >>>> The motivation of this draft is to extend dslite to re-use the same >>>> framework to provision a public IP to the B4 element and the AFTR not >>>>to >>>> NAT. I agree RFC5571 can achieve the same objective, but this will >>>>make >>>> the deployment easier to do two functions on the AFTR. Does this make >>>> sense to you? >>> >>> Yiu explained this to me during PCP, and I think I get it now. >>> >>> this is for the case where one has already deployed DS-lite to a >>>customer. >>> for whatever reason DS-lite fails for this end user (e.g. some >>> application doesn't work through the CGN). >>> >>> 4over6 provides a solution for provisioning a non NATed non port >>> restricted public IPv4 address to this end user. >>> >>> seems to me a very valid use case and something we should measure all >>>of >>> the 4 over 6 mechanisms (ds-lite, 4rd, divi...) against. >>> >>> cheers, >>> Ole >>> >> > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
