Hello Peng, Some comments inline...
On 11/3/11 5:12 AM, "Peng Wu" <[email protected]> wrote: > Hi Olivier, > > see inlines :) > -------------- > Peng Wu >> Hello, thanks for this interesting draft. >> >> In your use case, could you explain if every CPE/Host need to reach >> Internet? That would be the case in a typical Broadband deployment but >> perhaps not in your deployment scenario. > Could be every CPE/Host. >> >> If all CPE needs Internet access, all of them with an IP@ need a dedicated >> "bucket of ports" installed in the Concentrator. Which means that we could >> just have a static allocation of ports in the Concentrator instead of >> DHCP/PCP mechanism as described in your draft. > Well, we've thought of this. > There're two differences here. > > 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. > > 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. > 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. >> >> My point is we could have a Stateless mechanism in the Concentrator as >> described in SD-NAT (draft-penno-softwire-sdnat-01) and just use regular >> DHCP/Radius on the CPE to get a dynamic address allocation with the same >> result. >> >> What do you think? >> >> Cheers, >> Olivier >> >> >> On 11/2/11 8:06 AM, "peng-wu@foxmail" <[email protected]> wrote: >> >>> Hi all, >>> >>> We've submitted a -04 version of the b4-translated-ds-lite draft. >>> It describes the per-user-state IPv4-over-IPv6 mechanism with port set >>> support, which can be achieved through some extensions to ds-lite. >>> There are discussions going on upon this topic during and after the >>> Interim meeting. >>> We've received quite a lot offline comments/suggestions, and made >>> progresses accordingly. >>> >>> The draft is available on >>> http://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds-lite-04 >>> Please provide your valuable comments. And hopefully we'll present it in >>> Taipei. >>> >>> >>> >>> >>> >>> >>> >>> u--- >>> A new version of I-D, draft-cui-softwire-b4-translated-ds-lite-04.txt has >>> been successfully submitted by Qiong Sun and posted to the IETF >>> repository. >>> >>> Filename: draft-cui-softwire-b4-translated-ds-lite >>> Revision: 04 >>> Title: Lightweight 4over6 in access network >>> Creation date: 2011-10-30 >>> WG ID: Individual Submission >>> Number of pages: 24 >>> >>> Abstract: >>> The dual-stack lite mechanism provide an IPv4 access method over IPv6 >>> ISP network for end users. Dual-Stack Lite enables an IPv6 provider >>> to share IPv4 addresses among customers by combining IPv4-in-IPv6 >>> tunnel and Carrier Grade NAT. However, in dual-stack lite, CGN has >>> to maintain active NAT sessions, which could become the performance >>> bottom-neck due to high dynamics of NAT entries, memory cost and log >>> issue. This document propose the lightweight 4over6 mechanism which >>> moves the translation function from tunnel concentrator (AFTR) to >>> initiators (B4s), and hence reduces the mapping scale on the >>> concentrator to per-customer level. For NAT44 translation usage, the >>> mechanism allocates port restricted IPv4 addresses to initiators in a >>> flexible way independent of IPv6 network in the middle. >>> >>> >>> >>> >>> >>> The IETF Secretariat >>> >>> _______________________________________________ >>> Softwires mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/softwires >> >> >> > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
