Hello Yiu, Qiong, all,
Interesting discussion, and hope am not jumping too late! I guess I'm still
curing my jet lag. ;0
________________________________
From: Qiong [mailto:[email protected]]
Sent: Tuesday, August 09, 2011 2:49 PM
To: Lee, Yiu
Cc: [email protected]
Subject: Re: [Softwires] Clarification of the stateles/stateful
discussion
Hi Yiu, Jacni,
On Tue, Aug 9, 2011 at 9:25 AM, Lee, Yiu <[email protected]>
wrote:
So the only difference between 4rd BR and lightweight AFTR is
just a static mapping rule for all users in the same domain (4rd BR case) and
group rule or user specific rule for different users (LW AFTR)?
[Qiong]: Agree.
Xiaohong: If that's the only difference, don't see a need for two
different solutions.
And LW AFTR will not expose port-set information in IPv6 address
directly. So it would not introduce any specific requirements on IPv6 address
format. I think this is also a major difference between 4rd and Lightweight
4over6.
Xiaohong: Could you explain more about your concern on "specific
requirements on IPv6 address format"?
IMHO, I don't see a issue in 4rd IPv6 address format, as 4rd authors
have been carefully designing the port allocation algorithm for CE IPv6 prefix,
which is efficiently encoded (less than 64 bits) at least to my eyes. Open to
hear oppsite opinions if you have operation issues with your network. ;)
As a matter of fact, I see a need when a * incoming port * request is
out side 4rd port set, for example, UPnP 1.0 applications ask for a specific
port and try consecutive ports, RTP/RTCP and some FTP client implementations
ask for both even and odd ports pair, according to our A+P implementation, and
analysis and investigation of it's impact on current practice since 2009.
How to deal with incoming port out side of stateless solution is
something we have addressed by proposing a new port allocation algorithm and
implemented a scattered port allocation A+P, documented in A+P experiments
draft:
https://datatracker.ietf.org/doc/draft-deng-v6ops-aplusp-experiment-results
In case you're courious about port consumptions of applications in the
IPv4 address sharing context, you may like to have a look at:
http://opensourcev6transtechnologies.weebly.com/experiments-results.html
And it's also applicable to DS-Lite scenario, in case a deployment
wants to allocate a bulk of incoming ports to be under control of customer, a
deployment approach was documented in:
DS-Lite AFTR NAT Bypass: Co-located B4 and NAT Model
http://tools.ietf.org/html/draft-zhou-softwire-b4-nat-02
And the means of provisioning two parameters for this port allocation
is via PCP, and was documented in
http://tools.ietf.org/html/draft-tsou-pcp-natcoord-03
This deployment has been also demoed during IETF 81 PCP demo, and the
website for this demo has been moved to (in case you're into ascii drawings ;))
:
http://opensourcev6transtechnologies.weebly.com/ietf-81-pcp-demo-site.html
<http://opensourcev6transtechnologies.weebly.com/ietf-81-pcp-demo-site.html>
Thoughts are very much welcomed!
P.S. I'm not saying this algorithm is the only way for 4rd to deal with
incoming port restriction, and there are certainly ways to design 4rd port
allocation while keep its IPv6 prefix encoding efficiently. The point is that
there is a reason (current/past-to-be practice) for 4rd to take care of port
allocation.
_.._..,___,
( Cheers! )
]~,"-.-~ [
.=] ) ' (; ([
| ]:: ' [
'=]): .) ([
| : : |
~~~-------
Xiaohong
Best regards.
Qiong Sun
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
