[16NG] question about rfc4840
"Wei Gengyu" <weigengyu@vip.sina.com> Tue, 17 April 2007 12:23 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 1HdmiT-0000XW-VG; Tue, 17 Apr 2007 08:23:25 -0400
Received: from 16ng by megatron.ietf.org with local (Exim 4.43)
id 1HdmiR-0000Wv-VH
for 16ng-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 08:23:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43) id 1HdmiR-0000Wb-Kv
for 16ng@ietf.org; Tue, 17 Apr 2007 08:23:23 -0400
Received: from smtp.vip.sina.com ([202.108.3.172])
by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdmiL-00027f-Uv
for 16ng@ietf.org; Tue, 17 Apr 2007 08:23:23 -0400
Received: from DELLWEI (unknown [211.160.21.17])
by smtp.vip.sina.com (SINAMAIL) with ESMTP id D164E44A414
for <16ng@ietf.org>; Tue, 17 Apr 2007 20:23:08 +0800 (CST)
Message-ID: <001701c780eb$21d3ff80$a507740a@DELLWEI>
From: "Wei Gengyu" <weigengyu@vip.sina.com>
To: <16ng@ietf.org>
Date: Tue, 17 Apr 2007 20:22:52 +0800
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4
Subject: [16NG] question about rfc4840
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="===============1006547274=="
Errors-To: 16ng-bounces@ietf.org
Another question. In 3.1 Generality Even if a single encapsulation method is used, problems can still occur if demultiplexing of ARP, IPv4, IPv6, and any other protocols in use, is not supported at the link layer. While it is possible to demultiplex such packets based on the Version field (first four bits on the packet), this assumes that IPv4-only implementations will be able to properly handle IPv6 packets. As a result, a more robust design is to demultiplex protocols in the link layer, such as by assigning a different protocol type, as is done in IEEE 802 media where a Type of 0x0800 is used for IPv4, and 0x86DD for IPv6. Recommendations: Link-layer protocols should enable network packets (IPv4, IPv6, ARP, etc.) to be demultiplexed in the link layer. Demultipex is required at link layer as you recommended. But the problem is how to demultiplex. In IEEE802 media, as you said above, it use a Type field. This is link layer identification. And you also said to demultiplex packets based on the Version field. This is network layer identification. To demultiplex in link layer, I think the basic method should use differen link id, which may be the SAPI as LAPD, rather then the Type only. By considering the address and multiplex and demultiplex requirements, it should define a field of link id, which is an unique identifier of the logical link, in the header of link layer protocol. The link id can be an integer, the value is assigned when setup. In this way there are multiple logic links beween a pair of ajointing nodes. Each logic link can be unicast or multicast identified as usual. So, multiplex and demultiplex are accomplished at link layer, but what each link conveys is identified by the upper layer, i.e. in the header of network layer protocol, version or any other fields. I wonder wether it is the meaning of the recommendations. Regards, Gengyu
_______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng
- [16NG] question about rfc4840 Wei Gengyu