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

Hi Samita,
Please take consideration of the Appendix B as well regarding how to deal
with that in the next revision because there were concerns about that part
during the 70th meeting.

BR,
Junghoon

2007/12/8, Samita Chakrabarti <Samita.Chakrabarti@azairenet.com>om>:
>
>  NAT mention was added in appendix D as per Mr. OH's request.
>
> I am OK with removing it as there is nothing special in IPv4CS for NAT
> handling.
>
> It will be removed in next revision.
>
>
>
> -Samita
>
>
>  ------------------------------
>
> *From:* gabriel montenegro [mailto:gabriel_montenegro_2000@yahoo.com]
> *Sent:* Tuesday, November 20, 2007 10:21 AM
> *To:* soohong.park@samsung.com; 16ng@ietf.org
> *Subject:* Re: [16NG] Fwd: RE: RE: comment on draft of IPv4 over IEEE
> 802.16
>
>
>
> 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
>
> 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.16system, 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 <Samita.Chakrabarti@AzaireNet.com>
>
> *To:* Jongtaek Oh <jtoh@hansung.ac.kr>
>
> *Cc:* 박수홍책임 <soohong.park@samsung.com>
>
> *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 <Samita.Chakrabarti@AzaireNet.com>
>
> *To:* Syam Madanapalli <smadanapalli@gmail.com> ; Jongtaek Oh<jtoh@hansung.ac.kr>
>
> *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
>
>