I would like to ask gPXE maintainers/developers to have a look at
the IPv6 part of IPv6/DHCPv6 combo.
The git repository of gPXE with the stack is here:
If the stack is enabled (NET_PROTO_IPv6 in src/config.h), the image size
increase is about 4k. I think it will be possible to reduce this by
"uniting" (factoring out) arp and neighbour code and also fragment
reassembly of ipv4 and ipv6.
There is a README located in src/net/ipv6 dir.
I did a fare amount of debugging and testing, but skipped, for the time
being, fragment reassembly function. So the stack will drop fragmented
packets for now. As described in README, the ipv6 autoconf stuff should
Yuriy and I have implemented DHCPv6 part too but I still would like to
debug and test some more and also to try to factor out some similar
parts to reduce the size. I should be able to publish it in about a week,
at which point a real transfer of an image over IPv6 should be done
relatively easily (there is no DHCPv6 boot option, so we use vendor opt
which is not that straightforward).
I am looking forward to comments and suggestions which will help
to get to the point the IPv6 part can be merged.
Thanks in advance.
> Hello, Michael.
> We have some difficulty in passing source IP6 address to IP layer
> on tx path. The prototype for tx function in struct tcpip_net_protocol is
> int ( * tx ) ( struct io_buffer *iobuf,
> struct tcpip_protocol *tcpip_protocol,
> struct sockaddr_tcpip *st_dest,
> struct net_device *netdev,
> uint16_t *trans_csum );
> I know that in gPXE IPv4 the source address can be extracted from
> based on destination address. In IPv6 it is much harder to rely on
> such approach. For example, when we send a Neibour Solicitation to
> perform Duplicate Address Detection, our src is unspecified (all 0's),
> but when we send NS to resolve link address, we need to put our IP source
> address. We were coming up with different hacks to deal with this, but
> it's getting uglier and uglier.
> Since you did not object passing struct xfer_metadata meta through
> the stack, I was hoping it would be ok if we add meta argument to tx
> function of tcpip_net_protocol. In principle, in the long run, we could
> simply replace struct net_device *netdev argument with meta argument to
> keep the number of args the same (meta already has netdevice).
> But it may be more practical to use a 2 step approach.
> 1. We simply add meta arg which should not break anything and only our
> IPv6 stack starts using it.
> After we are sure that nothing is broken:
> 2. We remove netdev argument, and pass netdev through meta and
> change all other stacks accordingly.
> Also, it looks that struct sockaddr_tcpip *st_dest can also be passed
> using meta, so we might reduce the number of args for tx
> in tcpip_net_protocol.
> Thanks in advance for you comments.
>> I would accept a patch which uses the xfer_metadata structure as defined
>> in include/gpxe/xfer.h, and modifies the network stack to pass around a
>> struct xfer_metadata rather than passing e.g. link-layer source
>> as direct function parameters. This would bring the network stack into
>> closer alignment with the generic data-xfer interface used from the
>> TCP/UDP layer upwards.
> Igor V. Baryshev
> OKTET Labs
> Phone: +7 812 783 2191 Fax:+7 812 784 6591
Igor V. Baryshev
Phone: +7 812 783 2191 Fax:+7 812 784 6591