Rockets: not subtle.
Rocket science humor, on the other hand … Let’s clear up a few things with the IPv6 protocol and packets in general.
First of all: address space.
With IPv6, one can uniquely identify 3.4*10^38 items. Now, if we take all the solid components of a rover and lander and compress them together, it would make about 1 cubic meter. If that were entirely aluminum, there would be only 6*10^28 atoms. Without revealing too much, I can tell you we will not need 5 billion network addresses for each atom in our rover. In fact, to add perspective: someday, when we make the sun itself a fully functioning space station, IPv6 will let us support 200 billion network devices per cubic meter! So, we’re going to use a much smaller address space in our packets.
But, why bother with a smaller address space?
Let’s review some rules of good packet design:
Easy to route in hardware.
Simple (i. e. easily validated and verified) hardware should be able to move packets between subsystems without requiring mission-specific knowledge of the contained commands. While an address-free packet is technically smaller, using knowledge that commands such as “drive forward” only apply to a rover not to a lander, it rapidly explodes the testing work and greatly adds to risk.
Error corrected.
The physical transport of information can lose data. At a minimum, a system should be able to detect an error in a packet. Given the time delays and expense of a space mission, a system should be able to correct a little more than the expected typical error rate.
Minimum overhead / Maximum data to wrapper ratio.
Each bit sent into space is a chance to lose data. To send as few bits as possible, send as few packet wrappers around data as possible. An ideal protocol will vary this ratio depending upon quality of service feedback.
There is a balance between these design parameters.
For instance, most error correction schemes provide M bits of error correction for every N bits of data. Thus, there is a maximum packet size at which protection drops below mission standards. Sending very small commands makes for excellent error correction, but means more total bits sent into space and more chance for out of sequence or dropped packets, complicating the network software layer. Combining commands can increase overall throughput but reduces redundancy in the error correction. In addition, IPv6 is very easy to route with tested hardware and software already existing, but as it is larger than most commands, it significantly weakens error correction.
One must also consider mission timing.
When is your deadline and how long will the equipment remain operational? Equipment that will remain operational for many years will be valuable as a communication hub and should strive to use open standards. Short duration equipment, especially on a deadline, needs different engineering tradeoffs. Simple, robust FPGA designs are our preference. For now, we won’t be using the IPv6 headers on our packets, but we look forward to a future with a standards-based space communication network.
Once you’ve got a packet layout, you can work on a protocol, defining timeouts, forwarding, delay tolerance, and authentication. Seek the generalities within families of protocols. You’ll find hotly debated topics often to be single variable changes in the final code. Just remember that your goal is to reliably move information through space. Not on the ground and not within a subsystem in a rover, but through space!
If you are interested in everything around deep space communications, stay tuned! 
Wes Faler
A Part-Time Scientist
