Em Mon, Sep 26, 2005 at 10:10:33AM +0200, Lars Eggert escreveu:
> Hi,
>
> On Sep 26, 2005, at 4:15, Arnaldo Carvalho de Melo wrote:
> >Basicaly I did some more generalisations in the TCPv4/v6
> >infrastructure to
> >use it in DCCPv6, there are still several things to polish and
> >implement
> >but looks really nice so far, same flow as TCPv6, using
> >inet6_timewait_sock'ets, inet6_request_sock'ets, inet_diag/iproute2/ss
> >works just fine for IPv6 sockets, etc :-)
>
> great! To do this, did you need to go beyond what the current RFC-to-
> be DCCP drafts describe? (I haven't looked at the code.)
To be frank I haven't even looked at what the RFC-to-be drafts describe, it
was just an extension to the generalisations I did for turning code that
previously was TCP v4/v6 specific into generic INET transport protocols
infrastructure, used by both TCP and DCCP, lemme take a look at the draft
now... relevant bits:
9.1. Header Checksum Field
<snip>
The pseudoheader is calculated as for TCP. For IPv4, it is 96 bits
long, and consists of the IPv4 source and destination addresses, the
IP protocol number for DCCP (padded on the left with 8 zero bits),
and the DCCP length as a 16-bit quantity (the length of the DCCP
header with options, plus the length of any data); see RFC 793
(Section 3.1). For IPv6, it is 320 bits long, and consists of the
IPv6 source and destination addresses, the DCCP length as a 32-bit
quantity, and the IP protocol number for DCCP (padded on the left
with 24 zero bits); see RFC 2460 (Section 8.1).
<snip>
This one is pending, as I haven't enabled checksum verification in the
DCCPv6 code yet.
10.5. Congestion State
Has some info about reseting the congestion state in this case:
For example, an endpoint that sends or receives a Mobile IPv6 Binding
Update message [RFC 3775] SHOULD reset its congestion state for any
corresponding DCCP connections.
Haven't got to the mobile ipv6 part, not sure even if mobile IPv6 is
supported on Linux right now, last time I've heard its something to be done
in userspace, so when we get to this point, if it is implemented in
userspace we can have some setsockopt or ioctl to do what the draft states.
14.1. Measuring PMTU
Talks about IPv6 specific stuff, but PMTU in the Linux DCCP implementation
is very rough right now, so when getting to audit/polish/finish the
implementation I'll take that into account.
14.2. Sender Behavior
o On IPv6 connections whose applications have requested
fragmentation, the sender SHOULD use fragmentation extension
headers to fragment packets larger than PMTU into suitably-sized
chunks. (Those chunks are, of course, unfragmentable.)
Will have to check as well.
And thats about it for IPv6 in draft-ietf-dccp-spec-11.txt, possibly some
of these can leverage again on the TCPv6 code, will see when I got around
to these.
Right now I'm mostly interested in having the foundations in place, working
on generalising as much as possible and that makes sense among the TCP and
DCCP, v4 and v6 code in Linux, so as to reduce the maintainance cost and
leverage the wonderful work the TCP hackers done/will do, and so far this
is resulting in this:
[EMAIL PROTECTED] net-2.6]$ size OUTPUT/toy/net/dccp/dccp_ipv6.ko
text data bss dec hex filename
13218 1152 4 14374 3826 OUTPUT/toy/net/dccp/dccp_ipv6.ko
I.e. the DCCPv6 implementation on Linux is now, in its initial state, less
than 13KB of loadable module code size on IA32, with some debugging options
enabled 8-)
For reference here is the core + v4 size:
[EMAIL PROTECTED] net-2.6]$ size OUTPUT/toy/net/dccp/dccp.ko
text data bss dec hex filename
35995 1991 1032 39018 986a OUTPUT/toy/net/dccp/dccp.ko
Back to work on disentangling some TCP code in the ip v4/v6 layer
(IPV6_ADDRFORM setsockopt, etc) as we need that for DCCP as well, DCCP v4
mapped on v6 anyone? 8)
- Arnaldo
-
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
