Yiu, > 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? 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. 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
