Re: IP MPE payload

[Lloyd Wood <l.wood@eim.surrey.ac.uk>]

On Tue, 30 Oct 2001, Patrick Cipiere wrote:

> extract from ETSI document EN 301 192
> 
> > LLC_SNAP_flag: this is a 1-bit flag. If this flag is set to "1" the
> > payload carries an LLC/SNAP encapsulated datagram following the
> > MAC_address_1 field. The LLC/SNAP structure shall indicate the type of
> > the datagram conveyed. If this flag is set to "0", the section shall
> > contain an IP datagram without LLC/SNAP encapsulation. 
> 
> What about IPv4 vs IPv6?

the first few bits of the IP header are the version number. 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.

If the LLC_SNAP_flag is 1, the LLC/SNAP encapsulation must identify
the content it is carrying. normal layering.


> Any opinions about the way `IP datagram' should be interpreted?
> 
> 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.

I think your suggestion would break the existing mechanism, as well as
being unable to cope with any future version of IP beyond IPv6.

(I haven't seen the ETSI document you quote, but that extract seems
 quite sensible.)

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.

L.

<L.Wood@surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>