[16NG] Comments on IPv4CS subnet model and ARP
"Daniel Park" <soohongp@gmail.com> Thu, 14 June 2007 01:17 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 1Hydxm-0000BR-Tj; Wed, 13 Jun 2007 21:17:26 -0400
Received: from 16ng by megatron.ietf.org with local (Exim 4.43)
id 1Hydxl-00007I-HH
for 16ng-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 21:17:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43) id 1Hydxl-00005b-70
for 16ng@ietf.org; Wed, 13 Jun 2007 21:17:25 -0400
Received: from nz-out-0506.google.com ([64.233.162.236])
by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hydxj-0003RQ-Vk
for 16ng@ietf.org; Wed, 13 Jun 2007 21:17:25 -0400
Received: by nz-out-0506.google.com with SMTP id z31so377939nzd
for <16ng@ietf.org>; Wed, 13 Jun 2007 18:17:23 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition;
b=TggU7dzs8KZ+xOfukU80iaXCKGSkiG0gebdDclPwwf5+inYtJ0V7/autGpmlifAhVYuYbSHXJn5Xyf0YHvTx2L29RL3mI9/FYWzOFv0yGt5n9pXUv62Ezyi7mOwlMfNpu+0wjHlPngcc5YKjExcSR4IahiQ6uMrraYKOr4eeY9A=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition;
b=bH7JJqI6Sh43PsAT4BPSauNUQTFVsVdV8uR26IaYd1rRcNqO0+MhWr3eEKB3wUbi/YgM8OOMc/74IEZrs/VCT6gDHELe387r9S8XLfSq8LBqW6OSS9aPy3TYsmEdAq+DBS1caIPx9fLqcNNJ+2IA0KhNGvCujPSifn1E+bi86tc=
Received: by 10.114.209.1 with SMTP id h1mr1278340wag.1181783843017;
Wed, 13 Jun 2007 18:17:23 -0700 (PDT)
Received: by 10.114.134.4 with HTTP; Wed, 13 Jun 2007 18:17:22 -0700 (PDT)
Message-ID: <f7c7d76e0706131817h3953f8cfldfa53bb02bab9942@mail.gmail.com>
Date: Thu, 14 Jun 2007 10:17:22 +0900
From: "Daniel Park" <soohongp@gmail.com>
To: "16ng@ietf.org" <16ng@ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.5 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Cc: =?EUC-KR?B?sei7877w?= <sekim@kt.co.kr>
Subject: [16NG] Comments on IPv4CS subnet model and ARP
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>
Errors-To: 16ng-bounces@ietf.org
I am forwardig these comments originally from Sangeun Kim at KT to 16ng list. ======================================== 6. Subnet Model and IPv4 Address Assignment The Subnet Model recommended for IPv4 over IEEE 802.16 using IP CS is based on point-to-point link between MS and AR, hence each MS will be on different IP subnet. Proposed Changes: The Subnet Model recommended for IPv4 over IEEE 802.16 using IP CS is based on point-to-point link between MS and AR. 7. Address Resolution Protocol The IEEE 802.16 frame header does not contain the source and destination MAC addresses, instead it uses the Connection Identifier (CID) for the delivery of MAC frames. This makes classical Address Resolution Protocol (ARP) [3] trivial and unnecessary. > Also, IEEE 802.16 IPCS cannot classify the ARP packets as ARP runs directly over Ethernet and does not contain IP header. Thus ARP packets are not transmitted over IEEE 802.16 air interface when using IPCS. Proposed Changes: The IEEE 802.16 frame header does not contain the source and destination MAC addresses, instead it uses the Connection Identifier (CID) for the delivery of MAC frames. This makes classical Address Resolution Protocol (ARP) [3] trivial and unnecessary. Also, IEEE 802.16 IPCS cannot classify the ARP packets as ARP runs directly over Ethernet and does not contain IP header. Thus ARP packets are not transmitted over IEEE 802.16 air interface when using IPCS. However MS requires to proxy ARP function compatible with legacy IP host. -- Daniel Park _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng
- [16NG] Comments on IPv4CS subnet model and ARP Daniel Park
- RE: [16NG] Comments on IPv4CS subnet model and ARP Samita Chakrabarti
- [16NG] Comments on IPv4CS subnet model and ARP Behcet Sarikaya
- RE: [16NG] Comments on IPv4CS subnet model and ARP Samita Chakrabarti
- RE: [16NG] Comments on IPv4CS subnet model and ARP 김상언
- RE: [16NG] Comments on IPv4CS subnet model and ARP Samita Chakrabarti