Re: [16NG] Fwd: RE: RE: comment on draft of IPv4 over IEEE 802.16

gabriel montenegro <gabriel_montenegro_2000@yahoo.com> Tue, 20 November 2007 18:20 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 1IuXi7-0003pZ-5j; Tue, 20 Nov 2007 13:20:35 -0500
Received: from 16ng by megatron.ietf.org with local (Exim 4.43) id 1IuXi6-0003kz-2q for 16ng-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 13:20:34 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuXi5-0003kr-Jb for 16ng@ietf.org; Tue, 20 Nov 2007 13:20:33 -0500
Received: from web81905.mail.mud.yahoo.com ([68.142.207.184]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IuXi3-00045n-LS for 16ng@ietf.org; Tue, 20 Nov 2007 13:20:33 -0500
Received: (qmail 93799 invoked by uid 60001); 20 Nov 2007 18:20:31 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=mYWuHiVdgpIz27wq77i2W2jphabRp7GgGQ+hZDz0aFSraNvyE+LC81QDK1B14bxuV9FmyS3GnQFYLd7TDqapto06cuKDGtxD/CSew4/FOOXVf9uG2GJJlAFSA84au6z3KEEM8TJmRmyqZuhFQMyv2tbtcJwG0/1lLa5YKhSm1XE=;
X-YMail-OSG: _CzWbEgVM1lQqILiJVznGI3u6zyvegIpfNFvLi6GNLE0Y3mdgjrexMVT6bC2EDp9KVes5UT.Qywd2lUKsWg6zCP8hwoE48vsmohzZ1qSvURFPfRCcAFfthrPFg--
Received: from [24.16.82.16] by web81905.mail.mud.yahoo.com via HTTP; Tue, 20 Nov 2007 10:20:30 PST
X-Mailer: YahooMailRC/818.27 YahooMailWebService/0.7.152
Date: Tue, 20 Nov 2007 10:20:30 -0800 (PST)
From: gabriel montenegro <gabriel_montenegro_2000@yahoo.com>
Subject: Re: [16NG] Fwd: RE: RE: comment on draft of IPv4 over IEEE 802.16
To: soohong.park@samsung.com, 16ng@ietf.org
MIME-Version: 1.0
Message-ID: <176.93199.qm@web81905.mail.mud.yahoo.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a2c4a3535d1556ada67f8703d3d31591
Cc:
X-BeenThere: 16ng@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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="===============1195181707=="
Errors-To: 16ng-bounces@ietf.org

I disagree. I don't think we need to mention NAT, just like no other IPv4-over-foo document needs to mention NAT. That may be a reality
and its use common, but it is orthogonal to the business of carrying IPv4 packets over a given link layer. 

Furthermore, I believe the paragraph below is wrong. You don't need NAT in the AR. You can tunnel all the way to some other device (as
WiMAX does when Mobile IP modes are enabled). In this case, that other device *may* choose to do NAT, or not. But having a NAT in the
AR is most certainly not a generic requirement for IPv4.

-gabriel

----- Original Message ----
From: Daniel Park <soohong.park@samsung.com>
To: 16ng@ietf.org
Sent: Monday, November 19, 2007 3:44:05 PM
Subject: [16NG] Fwd: RE: RE: comment on draft of IPv4 over IEEE 802.16

Samsung Enterprise Portal mySingle
 

P, td, li {font-family:arial;font-size:9pt;margin-top:5px;margin-bottom:5px;}body{font-family:arial;font-size:9pt;}
 


<!--
 _filtered {font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
 _filtered {font-family:Batang;
panose-1:2 3 6 0 0 1 1 1 1 1;}
 _filtered {font-family:Gulim;
panose-1:2 11 6 0 0 1 1 1 1 1;}
 _filtered {font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
 _filtered {
panose-1:2 3 6 0 0 1 1 1 1 1;}
 _filtered {}
/* Style Definitions */

 p.MsoNormal, li.MsoNormal, div.MsoNormal

	{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:Gulim;}
a:link, span.MsoHyperlink

	{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed

	{color:blue;
text-decoration:underline;}
p

	{
margin-right:0in;

margin-left:0in;
font-size:12.0pt;
font-family:Gulim;}
span.EmailStyle18

	{
font-family:Arial;
color:navy;}
span.EmailStyle19

	{
font-family:Arial;
color:#993366;}
span.EmailStyle20

	{
font-family:Arial;
color:#003300;}
span.EmailStyle25

	{
font-family:Arial;
color:olive;}
 _filtered {
margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1

	{}
-->




Folks, 

 


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 
 












To: Jongtaek

Oh 
 



Cc: 박수홍책임 
 



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 
 



To: Syam

Madanapalli ; 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
 



  
 



  
















-----Inline Attachment Follows-----


_______________________________________________
16NG mailing list
16NG@ietf.org
https://www1.ietf.org/mailman/listinfo/16ng




_______________________________________________
16NG mailing list
16NG@ietf.org
https://www1.ietf.org/mailman/listinfo/16ng