lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] IPv6 design considerations


From: Ivan Delamer
Subject: [lwip-devel] IPv6 design considerations
Date: Mon, 8 Nov 2010 16:00:32 -0700 (MST)
User-agent: SquirrelMail/1.4.9a

Hi All,

As I let you know a couple of weeks ago, I'm working on IPv6 support in
LwIP. So far things are going well and there should be something useful in
a few weeks.

The objective is to simultaneously support IPv4 and IPv6. IPv6 support can
be commented out through #defines and #ifs so that code size and memory
use are not affected for IPv4 only compilation.

In order to achieve this support, not only need to insert new code and
struct fields in #if blocks, but some struct fields need to be changed. So
I want to put up some early design decisions for debate to make sure I get
it done right the first time. Please provide any feedback or suggestions
that are applicable.

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. All the IPv6 fields are #if'ed out
if necessary so that any pcbs remain the same size for v4-only
compilation.

This requires some refactoring, as all code must be changed as follows:
  pcb->local_ip   to:    pcb->local_ip.ip4

I hope it is acceptable to make this change throughout?


2) tcp_input, udp_input, raw_input, icmp6_input

When these functions are called, the pbuf points to the IP header. The
first thing these functions do is call pbuf_header and advance the
pointer. It would be very useful if these input functions were called with
the pbuf pointing to the IP payload. Some of the reasons are:
- v4 and v6 headers have different lenghts
- v6 header lengths are difficult to calculate if there are IP options
- Code would be more compact if the header removal code is in only one place

For those exceptional scenarios where tcp/udp need to take some info from
the IP header, this can be done through ip_current_header()

Would this be another accepatable change?


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.

I also added a new output function "output6" and and input function
"input6". These are the netif->output and netif->input equivalents for v6
packets. I thought ot keeping the original functions, but the input and
output functions would have to be bridges to ARP (v4) and ND (v6) modules
anyways, so not worth it.

Cheers
Ivan





reply via email to

[Prev in Thread] Current Thread [Next in Thread]