Subject: [16NG] question about rfc4840

From: "Wei Gengyu" <[email-masked]>
Date: Tue, 17 Apr 2007 20:22:52 +0800

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/16ng