MySQL Master 5.5 - Slave 5.6 - unknown system variable 'binlog_checksum', Error_code: 1193
If your run SHOW SLAVE STATUS\G on the Slave, and you see Slave_IO_Running: Yes, then the IO Thread is fine.
Notwithstanding, please note the Warnings

2016-11-18 22:48:03 12808 [Warning] Slave SQL: If a crash happens this configuration does not guarantee that the relay log info will be consistent, Error_code: 0

Error Code 0 means it's not an error, just informational.

2016-11-18 22:48:03 12808 [Warning] Slave I/O: Notifying master by SET @master_binlog_checksum= @@global.binlog_checksum failed with error: Unknown system variable 'binlog_checksum', Error_code: 1193

You mentioned the error involves the variable binlog_checksum.
According to the MySQL Documentation for binlog_checksum

Enabling this option causes the master to write checksums for events written to the binary log. Set to NONE to disable, or the name of the algorithm to be used for generating checksums; currently, only CRC32 checksums are supported. As of MySQL 5.6.6, CRC32 is the default.
This option was added in MySQL 5.6.2.

Since your Master is 5.5.42, there is no binlog_checksum available to compare the Master to the Slave. The warning is valid.
Perhaps setting binlog_checksum to 'NONE' on the Slave might disable this check.

2016-11-18 22:48:03 12808 [Warning] Slave I/O: Unknown system variable 'SERVER_UUID' on master. A probable cause is that the variable is not supported on the master (version: 5.5.42-log), even though it is on the slave (version: 5.6.31-log), Error_code: 1193

This is the same problem. The option server_uuid does not exist in MySQL 5.5.42 (the Master) as the message itself says.
EPILOGUE
As long as replication is running you are OK for the moment. It strongly recommend get your Master to MySQL 5.6.31 ASAP. Why ?
MySQL 5.6 introduced microseconds to DATETIME. If the Master (5.5.42) sends a DATETIME to the Slave (5.6.31), the IO Thread will break immediately. Please read my post from 2015-01-02 where I mentioned this.
You could work around this DATETIME mess by switching to STATEMENT replication (setting binlog_format to STATEMENT) on both Master (5.5) and Slave (5.6).