RE: [lwip-devel] IPv6 design considerations

[Kieran Mansley]

On Tue, 2010-11-09 at 08:07 -0500, Bill Auerbach wrote:
> >If that's enough that's fine. However, I would have thought we would
> >need a new ip_addr_t-like struct that contains both the union and a type
> >information (i.e. "isipv6"). For example, after creating a new tcp pcb,
> >it would be nice to just pass in the address and connect to whatever the
> >address points to. Otherwise, you would need different connect functions
> >for v4 and v6 (as the address then has a different type).
> >
> >The downside is that the size of ipv4 addresses increases (which is
> >quite optimal with 4 bytes, currently).
> 
> Maybe the 'isipv6' flag can be #if'ed out as well so the typedef for
> an IPv4 build is as it is now.  You would need more possibly empty
> macros to test the flag and to reference the ip address.  The good
> part about keeping it typedef'ed to a struct is that the compiler will
> do the copy whether it's IPv4 or IPv6 everywhere it's copied.  And
> most compilers are smart about seeing a 4-byte struct copy and *not*
> using memcpy.

In general I'm not all that concerned about keeping it looking like it
is now in the case where you don't have IPv6 configured.  If we go down
that route then IPv6 support will always be effectively bolted-on rather
than designed-in.

I'm happy to make exceptions in the cases where there are good reasons,
and this could well be one of them due to the efficiency of having 4
byte address structs for IPv4.  I just don't want to make the
implementation of IPv6 unnecessarily convoluted just to preserve the
current IPv4 code semantics.

Kieran