Re: future assignments of PPP protocol id's.

Drew Daniel Perkins <> Sun, 18 April 1993 06:29 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa06324; 18 Apr 93 2:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06320; 18 Apr 93 2:29 EDT
Received: from by CNRI.Reston.VA.US id aa08237; 18 Apr 93 2:28 EDT
Received: from by (5.61/UCD2.04) id AA00383; Sat, 17 Apr 93 23:08:21 -0700
Received: by (5.61/UCD2.04) id AA13432; Sat, 17 Apr 93 23:01:53 -0700
Received: from PO4.ANDREW.CMU.EDU by (5.61/UCD2.04) id AA13315; Sat, 17 Apr 93 22:59:25 -0700
Received: by (5.54/3.15) id <AA05878@X> for; Sun, 18 Apr 93 01:56:57 EDT
Received: via switchmail; Sun, 18 Apr 1993 01:56:53 -0400 (EDT)
Received: from via qmail ID </afs/>; Sun, 18 Apr 1993 01:56:26 -0400 (EDT)
Received: from via qmail ID </afs/>; Sun, 18 Apr 1993 01:56:25 -0400 (EDT)
Received: from via; Sun, 18 Apr 1993 01:56:25 -0400 (EDT)
Resent-Message-Id: <>
Resent-Date: Sun, 18 Apr 1993 01:56:25 -0400 (EDT)
Resent-From: Drew Daniel Perkins <>
Message-Id: <>
Date: Sun, 18 Apr 1993 01:55:32 -0400 (EDT)
From: Drew Daniel Perkins <>
To: Keith Sklower <>
Subject: Re: future assignments of PPP protocol id's.
In-Reply-To: <199304152149.OAA25222@vangogh.CS.Berkeley.EDU>
References: <199304152149.OAA25222@vangogh.CS.Berkeley.EDU>

Keith Sklower <> writes:
> [This begs the numerous PPP protocol id's
> less then 600 hex for the protocols themselves
> which you wouldn't want to use in ethernet packets
> because they might get taken for 802.3 lengths, and
> there are already common other numbers for them,
> like 800 for IP packets as an ethertype].
> I also asked Drew Perkins why it was that PPP
> protocol id's had an even first byte and an odd
> second byte. He said that was so they could be used
> as an HDLC two-byte address, but in fact this
> was something that was a hedge against a future
> day where it might be useful, and wasn't currently
> an absolute requirement; if there was a really good
> reason to give it up, current implementations
> of PPP wouldn't choke.  I'm not saying there is
> any good reason to give it up right now!
> (If they were used as an HDLC address, you would
> need to follow them with a UI, which is currently
> not being done).

Keith, we somehow miscommunicated.  I did NOT say that we wanted to
use protocol ids as addresses.  What I did try to say is the following:
1.  We wanted to have two octet addresses for high-speed links where
    processing speed was an important criteria and alignment issues
    might exist.
2.  We wanted to have one octet addresses for all important
    network-layer protocols when used with low-speed links where
    latency was an important criteria and alignment issues didn't exist.
3.  We realized that extensible protocol numbers would solve our
4.  We realized that CCITT had an existing methodology for implementing
    extensible fields, namely using the least-significant bit, and
    this was already in use by the HDLC address field (which we were
5.  Therefore, it made sense to use the same methodology for our
    protocol fields as we used for our HDLC address fields.

You also mentioned that changing this now would not break any
implementations.  This is definitely NOT true; it cannot now be changed.

Drew Perkins
4015 Holiday Park Drive			voice: (412) 325-1785
Murrysville, PA 15668			fax:   (412) 325-1344