Hi Reinaldo, I just took a brief look at draft-penno-softwire-sdnat-01, to get the basic idea. Not sure if I understand correctly.
This is a quite customized mechanism rather than just "static port set allocation in the concentrator". I guess that's why I'm confused by you last email, ha :) Regarding the DS-lite case, you kind of encode the port set index into the B4 IPv6 address, and than, achieve statelessness. The difference with the existing stateless mechanisms is that, you don't encode the public IPv4 address so you don't inform the customers this information. And you also need double translation to fit in the AFTR NAT, which is also different from the existing stateless mechanisms. This is quite interesting. It fits in the specific DS-lite case, but in general it's stateless mechanism. We kind of fall into different categories and use cases. Actually we have discussions on stateless vs. lightweight 4over6 in the Introduction part of our draft. For example, think of the case when either the B4 IPv6 addresses or the IPv4 address pool are scattered. Then the the statless mapping rule/algorithm on the AFTR can be quite complicated. -------------- Peng Wu >Hi Reinaldo, > >inlines :) >-------------- >Peng Wu > >>> The first and the major one is that, if we just take ds-lite and have static >>> port set allocation in the concentrator, the concentrator still has to keep >>> the per-session NAT table and perform the translation, while in lightweight >>> 4over6, NAT happens on CPE and the concentrator just perform >>> encapsulation/decapsulation, with a per-subscriber mapping table. >> >>Per-session NAT is not needed if: >> >>- the B4 performs NAT or >>- Each host has a unique IP and a known port space. >> >>Our implementation performs NAT without any per session state. >Could you go a little further into this? >I'm actually confused how you do NAT without (source IP, >source port, dst IP, dst port) mapping table > >> >>> >>> The second one is that in lightweight 4over6, with one-time DHCP/PCP, >>> the subscriber learns its public IPv4 address. This brings convenience and >>> eases the ALG problem to a certain extent. >> >>I think ALG is an application issue and can only be fully solved when all >>applications make use of PCP. >Well, my point is, if the whole problem is just a local 44NAT(as is in >leightweight 4over6), >then we already have uPnP, and end host don't need PCP to negotiate with the >AFTR >which is probably a remote, big network device. >> >>> In ds-lite with static concentrator >>> port allocation, the subscriber still doesn't know its public IPv4 >>> address/port >>> without per-session PCP process. >> >>Yes, that is a good point. We devised an extension to PCP to return the >>public IP and port range. Therefore a single message would be needed. >Similar idea. But I still need your elaboration on the principle of this > none-session-state NAT thing to get the whole picture. >> >_______________________________________________ >Softwires mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
