Re: IP MPE payload

[Patrick Cipiere <Patrick.Cipiere@udcast.com>]

Lloyd Wood wrote:

> the first few bits of the IP header are the version number.

I think I've already heard about this feature :-)

> Since you know it's an IP datagram because the LLC_SNAP_flag is 0,
> you know to pass it to code that will interpret it correctly based on
> the content of the version number field.

As you might expect, this is the way we handle this today.
But I don't like to decode layer 3 information in layer 2.

>> I think that LLC_SNAP_flag == 0 should (must?) be restricted to IPv4
>> (Ethertype 0x800) and for IPv6 LLC_SNAP_flag == 1 (Ethertype 0x86DD)

> but then you can't handle the encap/non-encap case.

No, I can handle both cases.

> I think your suggestion would break the existing mechanism,

No, I don't understand how this will break the existing mechanism.

> as well as
> being unable to cope with any future version of IP beyond IPv6.

Yes, if any future version of IP do not get a specific Ethertype.
Ethernet will face the same problem.

> I would guess that a reason IPv4 and v6 got given different
> ethertypes was because a lot of existing IPv4 implementations just
> didn't bother checking the IP header version field contents. Seems
> like an unnecessary kludge to me.

You are completely right.
If the IP stack can cope with the version field, we just have to send
the IP (v4 or v6) datagram to the IP layer.
Unfortunately most of the current IP stacks, are not ready for that.

So I guess we have to deal with it: we have 2 different Ethertype
values from IEEE for IPv4 and IPv6

0800 Internet IP (IPv4)        [IANA]
86DD IPv6                      [IANA]

Patrick.
-- 
UDcast: Full IP over Broadcast Media

Phone:  (+33) (0)4 93 00 16 99
Mobile: (+33) (0)6 14 21 55 98
Fax:    (+33) (0)4 93 00 16 61                 http://www.UDcast.com