Re: [lwip-devel] IPv6 design considerations

[Ivan Delamer]

Hello All and thank you for the feedback.

I will look into using the pre-processor as suggested by Bill, however I
must say that I did manually refactor the code in tcp/udp/raw/api and it
took less than an hour. I like seeing the IPv4 nametag on addresses
because the transport stack layers are tightly coupled at parts (for
efficiency), and it seems good to see clearly if it is coupled to IPv4 or
IPv6.

The array of IPv6 addresses is size configurable via
LWIP_IPv6_NUM_ADDRESSES, and could be as low as 1 for link-local-only
setups.

AutoIP6 is indeed Address Autoconfiguration as per RFC , using RA messages
as mentioned by Stephane. I kept the 'autoip' name for historical reasons,
but could be changed.

DHCPv6 is just a placeholder for now. I am not sure how much code can be
reused, but it should be possible to have a minimal implementation
available with a couple days effort.

About having IPv4 and IPv6 addresses all in one struct/union. I passed on
that idea for now for efficiency. I was thinking to follow the "one struct
for both" approach for Inet addresses used in the sockets layer. But I
haven't looked deep into this. With the current approach of having a union
in the PCB, it should not be hard to move that union out to ip_addr_t with
little impact on the rest of the code.

Cheers
Ivan


On Tue, November 9, 2010 00:04, Simon Goldschmidt wrote:
>
> "Ivan Delamer" <address@hidden> wrote:
>> 1) IP_PCB
>>
>> I have changed the field:
>>     ip_addr_t local_ip;
>> to
>>     union {
>>       ip_addr_t ip4;
>>       ip6_addr_t ip6;
>>     } local_ip;
>>
>> Same for remote_ip. I have also added a u8_t isipv6; field to determine
>> if
>> the PCB is for a v4 or v6 connection.
>
> 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).
>
>> [..]
>> This requires some refactoring, as all code must be changed as follows:
>>   pcb->local_ip   to:    pcb->local_ip.ip4
>
> With the above proposal, only the code that specifically knows it works on
> v4 addresses has to be changed (i.e. ".ip4" added), which shouldn't
> include too many files.
>
>> 2) tcp_input, udp_input, raw_input, icmp6_input
>> [..]
>
> Agreed. The current state is a bit awkward, anyway (it has been like that
> for "historical" reasons: ip_current_header has only been introduced
> lately).
>
>
>> 3) netif struct
>>
>> I have added an array of ip6_addr_t and some pointers to dhcp6 and
>> autoip6
>> structs. This seems pretty straight forward.
>
> Why add an array of ipv6 addresses? I would have thought on link-local
> address and one routable address should be enough for an embedded device?
>
> Did you implement dhcp6 already? I don't think you can just reuse dhcpv4
> (which should be moved to the ipv4 subdirectory, btw), can you?
>
> Oh, and isn't autoip a v4-only protocol? I thought v6 has link-local
> addresses assigned automatically?
>
>> I also added a new output function "output6" and and input function
>> "input6".
>
> Seems like the way to go, yes.
>
> I really appreciate your effort on this! I do hope this can be merged to
> CVS in the near future.
>
> Simon
> --
> GRATIS! Movie-FLAT mit über 300 Videos.
> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome
>