Hi Alain, I get what you are saying, but I still have one question: so this repository, is it dynamic is some way? For example, what happens if some user whose IPv6 address is not profiled requires enters, or some user is profiled leaves? Or we are supposing that the ISP knows all the user IPv6 prefixes and configures all the address mappings in some initial phase, so no matter what happens in the user side, the address mapping always remains?
This can help us to understand the SD-NAT draft more precisely. Thx~ 2012/3/20 Alain Durand <[email protected]>: > > On Mar 17, 2012, at 12:44 PM, Qi Sun wrote: > >> Hi Med, >> >> I've read through the draft-penno-* and IMHO it is reasonable in the >> view of deployment. By configuring the profile (i.e. the per-subscriber >> mapping table) in the AFTRs, the SPs can achieve an explicit binding between >> the IPv4 address + port-set and the customer. This can mean the customer pay >> for the ownership of the IPv4 address + port-set. It is easy to associate >> address(port-set) assignment with authentication. >> >> Best Regards! >> >> Qi Sun > > Thank you for your comment. Indeed, it is both simple and necessary to know > on the AFTR which ports belong to which subscriber. > > It is simple because this can be configured out-of-band (think netconf) from > a centralized repository. Note, that, using > a centralized repository for subscriber <--> IPv4 address & port mapping, > the service provider has the flexibility to > allocate different numbers of ports according to the subscriber profile. > More, because the association subscriber > <--> IPv4 address and port is known, there is no need for logging of any sort > on the AFTR. > > It is necessary because the AFTR is the only place where we can enforce IPv4 > ingress filtering, ie put ACLs to check > that the incoming tunneled traffic from any given customer is using a > legitimate IPv4 address and source port. > When the incoming traffic does not match those ingress filtering rules, an > ICMP error message must be returned. > The idea in SD-NAT is to use this ICMP message to carry the information about > the correct port range to use. > > Alain. > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
