Re: IP MPE payload

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

On Tue, 30 Oct 2001, Patrick Cipiere wrote:

> Lloyd Wood wrote:
> 
> > the first few bits of the IP header are the version number.
> 
> I think I've already heard about this feature :-)

good to know I'm not making things up.


> > 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.

you decode layer 3 information in layer 3; because you know it's an IP
packet directly encapsulated, you pass it straight up the stack to the
layer-3 handling code. Many implementations work that way.


> >> 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 don't follow this.

In your previous mail, you were suggesting redefining the bit from
indicating
(LLC_SNAP encap)/(raw IP datagram) to indicating
(raw IPv4 datagram)/(raw IPv6 datagram).

Which suggested you're after a convenient IP protocol indicator, and
do not need LLC_SNAP encapsulation - or have I misread your previous
email, or are you getting the information from somewhere else in the
header, suggesting that this bit may be redundant?

(I've downloaded ETSI EN 301 192 and am trying to translate the
datagram strucutre in the table on p13 into IETF/DoD ascii notation...
doesn't look like this bit is redundant unless e.g. private
descriptor/indicator or reserved MAC values are overloaded. And if
you're scrambling the payload do you really want to indicate what
you're carrying?

I have the suspicion that a misformatted Word table has messed up more
than one protocol spec...)


> > I think your suggestion would break the existing mechanism,
> 
> No, I don't understand how this will break the existing mechanism.

If that bit is the only way to indicate LLC/SNAP encapsulation, and it
is redefined to indicate IP protocol type (4/6), then LLC_SNAP
encapsulation cannot be indicated, yes?


> > 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.

they'll just define a new Ethertype (or reuse a value). 

> > 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.

Presumably you can snoop the payload and make the decision to pass it
to the stack, or discard it because thew stack doesn't support it,
yourself, if you're going to work with legacy stacks. (If you're
running separate IPv4 and IPv6 stacks on a box I suppose you probably
need to do that in your separate driver anyway.)

cheers,

L.

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