[16NG] Fwd: RE: RE: comment on draft of IPv4 over IEEE 802.16
Daniel Park <soohong.park@samsung.com> Mon, 19 November 2007 23:44 UTC
Return-path: <16ng-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1IuGHl-0000yV-1I; Mon, 19 Nov 2007 18:44:13 -0500
Received: from 16ng by megatron.ietf.org with local (Exim 4.43)
id 1IuGHj-0000yP-H7
for 16ng-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 18:44:11 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43) id 1IuGHj-0000yH-4m
for 16ng@ietf.org; Mon, 19 Nov 2007 18:44:11 -0500
Received: from mailout1.samsung.com ([203.254.224.24])
by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuGHf-0008QH-2l
for 16ng@ietf.org; Mon, 19 Nov 2007 18:44:11 -0500
Received: from ep_ms7_bk (mailout1.samsung.com [203.254.224.24])
by mailout1.samsung.com
(iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004))
with ESMTP id <0JRS0011K1XI4F@mailout1.samsung.com> for 16ng@ietf.org;
Tue, 20 Nov 2007 08:44:06 +0900 (KST)
Received: from ep_spt01 (ms7.samsung.com [203.254.225.101])
by ms7.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14
2004))
with ESMTP id <0JRS00AK61XH9L@ms7.samsung.com> for 16ng@ietf.org; Tue,
20 Nov 2007 08:44:05 +0900 (KST)
Content-return: prohibited
Date: Mon, 19 Nov 2007 23:44:05 +0000 (GMT)
From: Daniel Park <soohong.park@samsung.com>
To: 16ng@ietf.org
Message-id: <0JRS00AK71XH9L@ms7.samsung.com>
MIME-version: 1.0
MIME-version: 1.0
X-Priority: 3
Msgkey: 20071119233943844@soohong.park
X-MTR: 20071119233943844@soohong.park
X-EPLocale: ko_KR.euc-kr
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale: ML
X-EPHeader: ML
X-Generator: NamoMIME 6.0.0.3
X-Spam-Score: 0.5 (/)
X-Scan-Signature: b612707e1a3f67df80ae89cdab1ba981
Subject: [16NG] Fwd: RE: RE: comment on draft of IPv4 over IEEE 802.16
X-BeenThere: 16ng@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: soohong.park@samsung.com
List-Id: 16ng working group discussion list <16ng.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/16ng>,
<mailto:16ng-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/16ng>
List-Post: <mailto:16ng@ietf.org>
List-Help: <mailto:16ng-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/16ng>,
<mailto:16ng-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0252192267=="
Errors-To: 16ng-bounces@ietf.org
IPv4 document is newly taking care of NAT issue in Appendix D. I am forwarding the relevant threads to the list for further discussion and clarification. Do let us know if you have any concerns/questions...
Daniel Park
------- Original Message -------
Sender : Samita
Chakrabarti<Samita.Chakrabarti@AzaireNet.com>
Date : 2007-11-19 16:58
(GMT+09:00)
Title : RE: comment on draft of
IPv4 over IEEE 802.16
Hello Mr. Oh,
Thanks for the details explanation and need of the text for radio engineers.
We added your suggested text with a little modification at the appendix section.
Appendix D. Network Address Translation
There is not enough IPv4 address available, private IP address domain
has been used in deployment. If mobiles are assigned private IP
addresses from the DHCP server located in the access network, there
would be a NAT function in the Access router (AR) for address and
port translation;this is a generic requirement for private IPv4
address deployment model.
--
Thanks,
-Samita
From:
jtoh@hansung.ac.kr [mailto:jtoh@hansung.ac.kr]
Sent: Sunday, November 18, 2007
5:31 PM
To: Samita Chakrabarti
Cc: 박수홍책임
Subject: Re: comment on draft of
IPv4 over IEEE 802.16
Dear Samita
I'm sorry I couldn't catch it.
I added my comment at the end of the sentence.
[SC>] IMHO, the NAT function you are talking about in Appendix D. is generic for any gateway like ASN-GW or AR. We do not need to specifically say anything like “should”. Above, we should replace “should be NAT” to “could be NAT”. Also, we should remove “In addition, address filtering… “ line as this is very implementation specific.
=> Jongtaek: We are working for the IP interworking for IEEE 802.16 system, not for legacy Internet equipments, which hold common functions as we know.
So we should include everything important functions which must be included in the WiMAX or WiBro system for the services. Otherwise,
some manufacturer may implement address filtering, and the other companies will not. Then service interworking is not possible.
That is the reason why standardization is necessary. Ambiguous assumption is not good approaching method.
Addressing filtering and/or address mapping is very important functions for IP applications. For WiMAX network, there are two kinds of
different networks are combined, Internet and wireless network system. In order to provide versatile Internet services, destination IP addresses
should be managed and can be modified. For example, for MBS services, the technologies proposed by Samsung and me need IP address
mapping scheme at AR and/or BS. 16ng WG should see the background of the sentences.
NAT and address filtering are very familiar with Internet society, but they are not default functions for radio engineers. The RFCs relevant to
IEEE802.16 could be used for radio engineers also.
For the above comment, "should" could be changed "could", but the sentence about "address filtering" should be remained. It has no harm,
but it has value more than "informative".
Thank you, Samita.
Jongtaek Oh
----- Original Message -----
From: Samita.Chakrabarti@AzaireNet.com" rel="nofollow">Samita Chakrabarti
To: jtoh@hansung.ac.kr" rel="nofollow">Jongtaek Oh
Cc: soohong.park@samsung.com" rel="nofollow">박수홍책임
Sent: Sunday, November 18, 2007 4:25 PM
Subject: RE: comment on draft of IPv4 over IEEE 802.16
Hi Mr. Oh:
Sorry my comment was hiding below toward the end of the mail, so you did not catch it.
Here it is:
----- Original Message -----
From: Samita.Chakrabarti@AzaireNet.com" rel="nofollow">Samita Chakrabarti
To: smadanapalli@gmail.com" rel="nofollow">Syam Madanapalli ; jtoh@hansung.ac.kr" rel="nofollow">Jongtaek Oh
Sent: Friday, November 16, 2007 6:40 AM
Subject: RE: comment on draft of IPv4 over IEEE 802.16
Hi All,
Appendix D. Network Address Translation
There is not enough IPv4 address available, private IP address domain has been used publicly. When MSs are given private IP address from DHCP server, there should be NAT function in AR, which changes public IP address into private address, and vise versa. In addition, address filtering and/or address mapping to another address could be used.
<Syam> I understand your concern, but I am not sure if this is required, But I can include this text in the
draft to get some feedback from the WG.
[SC>] IMHO, the NAT function you are talking about in Appendix D. is generic for any gateway like ASN-GW or AR. We do not need to specifically say anything like “should”. Above, we should replace “should be NAT” to “could be NAT”. Also, we should remove “In addition, address filtering… “ line as this is very implementation specific.
Thanks,
-Samita
_______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng
- [16NG] Fwd: RE: RE: comment on draft of IPv4 over… Daniel Park
- Re: [16NG] Fwd: RE: RE: comment on draft of IPv4 … gabriel montenegro
- Re: [16NG] Fwd: RE: RE: comment on draft of IPv4 … Jongtaek Oh
- RE: [16NG] Fwd: RE: RE: comment on draft of IPv4 … Samita Chakrabarti
- Re: [16NG] Fwd: RE: RE: comment on draft of IPv4 … Jongtaek Oh
- Re: [16NG] Fwd: RE: RE: comment on draft of IPv4 … Junghoon Jee