Re: [Softwires] Port mapping - Don't change it at the last minute !
Hi Jacni, Le 3 nov. 2011 à 05:13, Jacni Qin a écrit : ... Saying if you are not happy with port sharing, we give you a full address is relatively straightforward and can be translated into marketing terms. Anything in between is more questionable. This is a question that should be taken back to the working group: how far do we want to go on that route. Indeed. +1 In addition, Although according to the current algorithm, both the prefix case and the exclusive address case can be inherently supported, I still think, at least to cover the prefix case is debatable, given the so called residual deployment of IPv4, which is the context of the solution design. Furthermore, there is already an approach adopted by the WG for public IPv4 address case, if the MAP just covers shared address with one single sharing ratio for one domain, the design will be greatly simplified? Requiring ISPs to maintain IPv4 routing in their networks, just to serve the few users that need to keep IPv4 prefixes, seems to me a step backward. Besides, I have serious doubts about greatly simplified. In my understanding, the recent unifying design of 4rd-U is, among per-customer-stateless v4/v6 solutions, one that permits a UNIQUE AND SIMPLE standard (possible direct CE-CE routes, transparency to v4 fragmentation, compatibility with v6 OM-tools). All clarification questions are of course welcome. Cheers, RD ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Port mapping - Don't change it at the last minute !
Remi, [...] Furthermore, there is already an approach adopted by the WG for public IPv4 address case, if the MAP just covers shared address with one single sharing ratio for one domain, the design will be greatly simplified? Requiring ISPs to maintain IPv4 routing in their networks, just to serve the few users that need to keep IPv4 prefixes, seems to me a step backward. can you clarify why this? I don't understand why IPv4 routing has to be maintained just because there is a MAP domain with full IPv4 addresses (or a rule for full IPv4 addresses)? cheers, Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
[Softwires] Keeping support of CE IPv4 prefixes in the v4/v6 address mapping?
Le 3 nov. 2011 à 09:50, Jacni Qin a écrit : if the MAP just covers shared address with one single sharing ratio for one domain, the design will be greatly simplified? Requiring ISPs to maintain IPv4 routing in their networks, just to serve the few users that need to keep IPv4 prefixes, seems to me a step backward. Besides, I have serious doubts about greatly simplified. I mean for the design of the address/port mapping algorithm, not the transport mechanism. Yes, but I don't see the great simplification of the algorithm. Keeping it general enough to support IPv4 prefixes is AFAIK easy. It doesn't prevent deployments where, IPv4 prefixes being not supported, fields can be at places that may be found more convenient. Maybe you can be more specific on your concern. Cheers, RD ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Keeping support of CE IPv4 prefixes in the v4/v6 address mapping?
Hi Rémi, all, Since there is only an excerpt of e-mails, I lost the context. Could you please clarify what is the issue discussed here? Thanks. Cheers, Med -Message d'origine- De : Rémi Després [mailto:despres.r...@laposte.net] Envoyé : jeudi 3 novembre 2011 10:05 À : Jacni Qin Cc : Alain Durand; Ole Troan; BOUCADAIR Mohamed OLNC/NAD/TIP; Satoru Matsushima; Softwires WG Objet : Keeping support of CE IPv4 prefixes in the v4/v6 address mapping? Le 3 nov. 2011 à 09:50, Jacni Qin a écrit : if the MAP just covers shared address with one single sharing ratio for one domain, the design will be greatly simplified? Requiring ISPs to maintain IPv4 routing in their networks, just to serve the few users that need to keep IPv4 prefixes, seems to me a step backward. Besides, I have serious doubts about greatly simplified. I mean for the design of the address/port mapping algorithm, not the transport mechanism. Yes, but I don't see the great simplification of the algorithm. Keeping it general enough to support IPv4 prefixes is AFAIK easy. It doesn't prevent deployments where, IPv4 prefixes being not supported, fields can be at places that may be found more convenient. Maybe you can be more specific on your concern. Cheers, RD ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
[Softwires] MAP design team output
All,
after the Softwires Interim meeting in Beijing, a design team was tasked with
producing a document with a common mechanism for Mapping of Address and Port. a
mechanism that could be common for all the proposed stateless IPv4 over IPv6
mechanisms (dIVI-PD, 4rd-{E,T,U}, Stateless 4over6, SA46T-AS).
the latest document is available here:
http://tools.ietf.org/html/draft-mdt-softwire-mapping-address-and-port-01
this is the work of the design team (consisting of most of authors of the above
mentioned proposals). this does not in any way represent working group
consensus of course. please comment and review as for any other individual
submission.
there is an appendix in the draft listing current open issues. these issues the
design team could not reach consensus on and we would very much like the
working group's input on these. I will initiate separate threads for each of
the items in the list shortly.
cheers,
Ole
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Keeping support of CE IPv4 prefixes in the v4/v6 address mapping?
Le 3 nov. 2011 à 10:14, mohamed.boucad...@orange.com mohamed.boucad...@orange.com a écrit : Hi Rémi, all, Since there is only an excerpt of e-mails, I lost the context. Could you please clarify what is the issue discussed here? Thanks. Sure. Right or wrong, I understood that what Jacni suggested is that the v4/v6 address mapping would be able to assign full IPv4 addresses to CEs, but no longer IPv4 prefixes. If I misunderstood, end of this subject for me. Otherwise, I argue that keeping IPv4-prefix support isn't difficult. Hope it clarifies. Cheers, RD Cheers, Med -Message d'origine- De : Rémi Després [mailto:despres.r...@laposte.net] Envoyé : jeudi 3 novembre 2011 10:05 À : Jacni Qin Cc : Alain Durand; Ole Troan; BOUCADAIR Mohamed OLNC/NAD/TIP; Satoru Matsushima; Softwires WG Objet : Keeping support of CE IPv4 prefixes in the v4/v6 address mapping? Le 3 nov. 2011 à 09:50, Jacni Qin a écrit : if the MAP just covers shared address with one single sharing ratio for one domain, the design will be greatly simplified? Requiring ISPs to maintain IPv4 routing in their networks, just to serve the few users that need to keep IPv4 prefixes, seems to me a step backward. Besides, I have serious doubts about greatly simplified. I mean for the design of the address/port mapping algorithm, not the transport mechanism. Yes, but I don't see the great simplification of the algorithm. Keeping it general enough to support IPv4 prefixes is AFAIK easy. It doesn't prevent deployments where, IPv4 prefixes being not supported, fields can be at places that may be found more convenient. Maybe you can be more specific on your concern. Cheers, RD ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
[Softwires] Keeping support of CE IPv4 prefixes in the v4/v6 address mapping?
Le 3 nov. 2011 à 10:04, Ole Troan a écrit : ... Requiring ISPs to maintain IPv4 routing in their networks, just to serve the few users that need to keep IPv4 prefixes, seems to me a step backward. can you clarify why this? I don't understand why IPv4 routing has to be maintained just because there is a MAP domain with full IPv4 addresses (or a rule for full IPv4 addresses)? I didn't say that. IF the address mapping can't assign IPv4 prefixes to CEs, AND IF an ISP has to support some users needing IPv4 prefixes, it needs a tool to do it. I supposed that maintaining IPv4 routing was the easiest way to do it. If you have a better alternative, what would it be? As said to Med, if I misunderstood Jacni's idea, this debate can be closed. Cheers, RD ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Fw: New Version Notification fordraft-cui-softwire-b4-translated-ds-lite-04.txt
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. 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. In ds-lite with static concentrator port allocation, the subscriber still doesn't know its public IPv4 address/port without per-session PCP process. 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 peng...@foxmail.com 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 Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Keeping support of CE IPv4 prefixes in the v4/v6 address mapping?
As far as I understood, keeping IPv4 prefix in the mapping facilitated the use of IPv4 subnets, am I interpreting it right? Regards, Tina -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of Rémi Després Sent: Thursday, November 03, 2011 2:23 AM To: mohamed.boucad...@orange.com Cc: Softwires WG; Ole Troan Subject: Re: [Softwires] Keeping support of CE IPv4 prefixes in the v4/v6 address mapping? Le 3 nov. 2011 à 10:14, mohamed.boucad...@orange.com mohamed.boucad...@orange.com a écrit : Hi Rémi, all, Since there is only an excerpt of e-mails, I lost the context. Could you please clarify what is the issue discussed here? Thanks. Sure. Right or wrong, I understood that what Jacni suggested is that the v4/v6 address mapping would be able to assign full IPv4 addresses to CEs, but no longer IPv4 prefixes. If I misunderstood, end of this subject for me. Otherwise, I argue that keeping IPv4-prefix support isn't difficult. Hope it clarifies. Cheers, RD Cheers, Med -Message d'origine- De : Rémi Després [mailto:despres.r...@laposte.net] Envoyé : jeudi 3 novembre 2011 10:05 À : Jacni Qin Cc : Alain Durand; Ole Troan; BOUCADAIR Mohamed OLNC/NAD/TIP; Satoru Matsushima; Softwires WG Objet : Keeping support of CE IPv4 prefixes in the v4/v6 address mapping? Le 3 nov. 2011 à 09:50, Jacni Qin a écrit : if the MAP just covers shared address with one single sharing ratio for one domain, the design will be greatly simplified? Requiring ISPs to maintain IPv4 routing in their networks, just to serve the few users that need to keep IPv4 prefixes, seems to me a step backward. Besides, I have serious doubts about greatly simplified. I mean for the design of the address/port mapping algorithm, not the transport mechanism. Yes, but I don't see the great simplification of the algorithm. Keeping it general enough to support IPv4 prefixes is AFAIK easy. It doesn't prevent deployments where, IPv4 prefixes being not supported, fields can be at places that may be found more convenient. Maybe you can be more specific on your concern. Cheers, RD ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Fw: New Version Notification fordraft-cui-softwire-b4-translated-ds-lite-04.txt
Hello Peng, Some comments inline... On 11/3/11 5:12 AM, Peng Wu peng...@foxmail.com 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 peng...@foxmail.com 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 Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] [BEHAVE] Stateless Deterministic NAPT/DS-Lite
Just to make sure I understand this. Deterministic (statefull) NAT is deterministically translating inside IP to outside IP + port range (take NAT44 case). Deterministic stateLESS NAT is deterministically translating inside IP + inside_src_port to outside IP + outside_src_port. No states are required since the incoming traffic in the downstream direction (outside IP +port) can be deterministically translated to inside IP+port. Any incoming traffic from outside will be mapped to something (predictable) on the inside even though there may be no traffic initiated from the inside. CPE still needs statefull NAT. Is this correct? Thanks, Kris -Original Message- From: behave-boun...@ietf.org [mailto:behave-boun...@ietf.org] On Behalf Of Reinaldo Penno Sent: Tuesday, November 01, 2011 4:12 PM To: softwires@ietf.org; beh...@ietf.org Subject: [BEHAVE] Stateless Deterministic NAPT/DS-Lite Hello, we submitted a new draft detailing our implementation of Stateless-Deterministic NAPT44 and DS-Lite. (SD-NAT) http://tools.ietf.org/html/draft-penno-softwire-sdnat-01 This is a based on our experience with port bucket/chunk allocation and deterministic NAPT44. In the draft we provide a comparison with other stateless/stateful methods floating around. Thanks, Reinaldo ___ Behave mailing list beh...@ietf.org https://www.ietf.org/mailman/listinfo/behave ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] [BEHAVE] Stateless Deterministic NAPT/DS-Lite
Hello Kristian, comments inline. On 11/3/11 4:38 PM, Poscic, Kristian (Kristian) kristian.pos...@alcatel-lucent.com wrote: Just to make sure I understand this. Deterministic (statefull) NAT is deterministically translating inside IP to outside IP + port range (take NAT44 case). Yes. Deterministic stateLESS NAT is deterministically translating inside IP + inside_src_port to outside IP + outside_src_port. No states are required since the incoming traffic in the downstream direction (outside IP +port) can be deterministically translated to inside IP+port. Any incoming traffic from outside will be mapped to something (predictable) on the inside even though there may be no traffic initiated from the inside. Correct, no need for previous outbound packet. Subscriber gets port forwarding naturally as a consequence. CPE still needs statefull NAT. Is this correct? Yes. Thanks, Kris -Original Message- From: behave-boun...@ietf.org [mailto:behave-boun...@ietf.org] On Behalf Of Reinaldo Penno Sent: Tuesday, November 01, 2011 4:12 PM To: softwires@ietf.org; beh...@ietf.org Subject: [BEHAVE] Stateless Deterministic NAPT/DS-Lite Hello, we submitted a new draft detailing our implementation of Stateless-Deterministic NAPT44 and DS-Lite. (SD-NAT) http://tools.ietf.org/html/draft-penno-softwire-sdnat-01 This is a based on our experience with port bucket/chunk allocation and deterministic NAPT44. In the draft we provide a comparison with other stateless/stateful methods floating around. Thanks, Reinaldo ___ Behave mailing list beh...@ietf.org https://www.ietf.org/mailman/listinfo/behave ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Keeping support of CE IPv4 prefixes in the v4/v6 address mapping?
hi Remi, On 11/3/2011 5:04 PM, Rémi Després wrote: Le 3 nov. 2011 à 09:50, Jacni Qin a écrit : if the MAP just covers shared address with one single sharing ratio for one domain, the design will be greatly simplified? Requiring ISPs to maintain IPv4 routing in their networks, just to serve the few users that need to keep IPv4 prefixes, seems to me a step backward. Besides, I have serious doubts about greatly simplified. I mean for the design of the address/port mapping algorithm, not the transport mechanism. Yes, but I don't see the great simplification of the algorithm. Keeping it general enough to support IPv4 prefixes is AFAIK easy. It doesn't prevent deployments where, IPv4 prefixes being not supported, fields can be at places that may be found more convenient. Right, and I have already mentioned that in my previous message, the prefix case can be inherently supported. I just said that in the context of IPv4 address shortage, it may be not reasonable. If the sharing ratio is unique, then it'll be easily to be calculated, some parameter is not required in the MAP Rule. And the simplicity can also mean straightforward to implementers and addressing planners, which IMHO is important for the solution to be accepted easily in practice. Cheers, Jacni Maybe you can be more specific on your concern. Cheers, RD ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Keeping support of CE IPv4 prefixes in the v4/v6 address mapping?
hi, On 11/3/2011 5:24 PM, Rémi Després wrote: Le 3 nov. 2011 à 10:04, Ole Troan a écrit : ... Requiring ISPs to maintain IPv4 routing in their networks, just to serve the few users that need to keep IPv4 prefixes, seems to me a step backward. can you clarify why this? I don't understand why IPv4 routing has to be maintained just because there is a MAP domain with full IPv4 addresses (or a rule for full IPv4 addresses)? I didn't say that. IF the address mapping can't assign IPv4 prefixes to CEs, AND IF an ISP has to support some users needing IPv4 prefixes, it needs a tool to do it. I supposed that maintaining IPv4 routing was the easiest way to do it. If you have a better alternative, what would it be? If the customer is likely to pay that much for a prefix, I guess these won't be a problem any more. For example, just setup a dedicated tunnel and add a piece of route for them. Cheers, Jacni As said to Med, if I misunderstood Jacni's idea, this debate can be closed. Cheers, RD ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Fw: New Version Notificationfordraft-cui-softwire-b4-translated-ds-lite-04.txt
Hi，Peeno， In section 4.5 of the SDNAT draft you've given a mapping function example. I'm not quite get the meaning of the stateless algorithm. Say the maxpot is 1024, so we get the i = floor((65535-1024) / 1024 ) = 63. I cannot find the definition of the P, does it mean the number of addresses in the address pool? If it is, what's the mean by floor(i / p)? Or maybe I misunderstand the meaning... Best Regards! Jiang Dong Hello Peng, Some comments inline... On 11/3/11 5:12 AM, Peng Wu peng...@foxmail.com 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 peng...@foxmail.com 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 Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires
