[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