Broccoli uses the following structure to represent addresses:
typedef struct bro_addr {
uint32 addr[4]; /**< IP address in network byte order */
int size; /**< Number of 4-byte words occupied in addr */
} BroAddr;
Why do we need the second field? That is, why don't we use a single 16 byte
array, where the version distinction occurs implicitly through the IPv4
mapped prefix (as in Bro)?
Matthias
Broccoli uses the following structure to represent addresses:
typedef struct bro_addr {
uint32 addr[4]; /**< IP address in network byte order */
int size; /**< Number of 4-byte words occupied in addr */
} BroAddr;Why do we need the second field? That is, why don't we use a single 16 byte
array, where the version distinction occurs implicitly through the IPv4
mapped prefix (as in Bro)?
I think I had done that just to be more like how the serialization process in Bro represents addresses as the length of the address in bytes followed by the address, but it could also construct the IPv4 mapped addresses like you said instead and it would be fine, too. Think it's worth changing?
Should we also change the serialization to always represent addresses as 16 bytes? Seems inefficient right now, but I guess it would eventually become better once IPv6 addresses are the more frequent type.
+Jon
I think I had done that just to be more like how the serialization
process in Bro represents addresses as the length of the address in
I actually prefer the explicit size field for Broccoli but for a
different reason: it makes it easier for applications to differentiate
between IPv4 and v6. Otherwise, each client application needs to
implement our v4-in-v6 mapping in same way (even if standard).
With that reasoning, we could even make it more explicit: instead of
giving size, give the protocol directly and use a union with separate
fields for v4 and v6 address.
Should we also change the serialization to always represent addresses
as 16 bytes? Seems inefficient right now, but I guess it would
eventually become better once IPv6 addresses are the more frequent
type.
(No opionion here, fine either way).
Robin
I actually prefer the explicit size field for Broccoli but for a
different reason: it makes it easier for applications to differentiate
between IPv4 and v6. Otherwise, each client application needs to
implement our v4-in-v6 mapping in same way (even if standard).
I see your point, but wouldn't it suffice to provide an additional
boolean Broccoli function for that purpose?
Should we also change the serialization to always represent addresses
as 16 bytes? Seems inefficient right now, but I guess it would
eventually become better once IPv6 addresses are the more frequent
type.(No opionion here, fine either way).
I agree with Jon that such a change may not yet amortize, but at some
point in the future. We could still revisit it then.
Matthias
implement our v4-in-v6 mapping in same way (even if standard).
(FYI, it is indeed standard)
Sure, that would work as well.
Robin