Re: [ANN] 1st release of USAGI IPv6 environment

[Aki M Laukkanen <amlaukka@xxxxxxxxxxxxxx>]

On Wed, 1 Nov 2000, usagi-core wrote:
> We are glad to announce the 1st release of USAGI Project. The "USAGI"
> means UniverSAl playGround for Ipv6. It is the IPv6 development project
> for Linux operating systems mainly.

Great to hear about this project. Looked at the site.
Would you like to elaborate on some of the goals?

* Anycast
* Routing header

* IPSec 

http://www.freeswan.org/ is the project implementing IPSec etc.
on Linux. They do not yet have IPv6 support but I think it's in the 
plans. If you're going to work on IPSec, you might want to cooperate
with them.

* Mobile IPv6

The GO Project at Helsinki University of Technology is implementing
IP Mobility support for IPv6.

http://vesper.tky.hut.fi/mip/

You seem to have evaluated the Linux stack with some kind of evaluation
suite (pointer?). However the kernel used was 2.2.15. Have you run the
same tests on 2.4.0-testxx?

> features such as IPsec and NDP are missing or miss-implemented.

NDP? Does it refer to Neighbor Discovery?

Btw. to get more familiar with IPv6 and the Linux implementation of it,
I started evaluating the stack with by checking each requirement in
RFC to how it was done in the code. This far I've only done RFC 2460.
The full report is available at:

http://www.cs.helsinki.fi/u/amlaukka/rfc2460.eval

I would appreciate if Dave, Alexei or Andi could look at it and 
comment on it. I'm sure you are keeping such a list already and
I'd like to know, to what extent this is duplicated effort. If
you think this is needed, I could proceed to ND, SAA etc?

Basically the old RFC 1883 (or thereabouts) shows only in the
user-space exported structures ipv6hdr and rt0_hdr. The code in
kernel does not reflect the priority vs. traffic class and bitmap
fields anymore. The attached patch changes these but it seems more
of a policy issue to leave them as is:

diff -urN linux-2.4.0-test10/include/linux/ipv6.h 
linux-2.4.0-test10.ipv6/include/linux/ipv6.h
--- linux-2.4.0-test10/include/linux/ipv6.h     Tue Oct  3 22:02:03 2000
+++ linux-2.4.0-test10.ipv6/include/linux/ipv6.h        Sat Nov  4 22:55:10 2000
@@ -67,7 +67,7 @@
 
 struct rt0_hdr {
        struct ipv6_rt_hdr      rt_hdr;
-       __u32                   bitmap;         /* strict/loose bit map */
+       __u32                   reserved;
        struct in6_addr         addr[0];
 
 #define rt0_type               rt_hdr.type;
@@ -76,22 +76,20 @@
 /*
  *     IPv6 fixed header
  *
- *     BEWARE, it is incorrect. The first 4 bits of flow_lbl
- *     are glued to priority now, forming "class".
  */
 
 struct ipv6hdr {
 #if defined(__LITTLE_ENDIAN_BITFIELD)
-       __u8                    priority:4,
-                               version:4;
+       __u32                   flow_lbl:20,
+                               traffic_class:8,
+                               version:4;
 #elif defined(__BIG_ENDIAN_BITFIELD)
-       __u8                    version:4,
-                               priority:4;
+       __u32                   version:4,
+                               traffic_class:8,
+                               flow_lbl:20;
 #else
 #error "Please fix <asm/byteorder.h>"
 #endif
-       __u8                    flow_lbl[3];
-
        __u16                   payload_len;
        __u8                    nexthdr;
        __u8                    hop_limit;
diff -urN linux-2.4.0-test10/net/ipv6/exthdrs.c 
linux-2.4.0-test10.ipv6/net/ipv6/exthdrs.c
--- linux-2.4.0-test10/net/ipv6/exthdrs.c       Sun Jan  9 07:36:21 2000
+++ linux-2.4.0-test10.ipv6/net/ipv6/exthdrs.c  Sat Nov  4 23:26:07 2000
@@ -345,7 +345,7 @@
        memcpy(opt->srcrt, hdr, sizeof(*hdr));
        irthdr = (struct rt0_hdr*)opt->srcrt;
        /* Obsolete field, MBZ, when originated by us */
-       irthdr->bitmap = 0;
+       irthdr->reserved = 0;
        opt->srcrt->segments_left = n;
        for (i=0; i<n; i++)
                memcpy(irthdr->addr+i, rthdr->addr+(n-1-i), 16);


(Disclaimer: I didn't actually try to compile the code).

Another issue which seems like a genuine bug is the handling reassembling
the fragmented packets. In some cases skb seems to be freed twice (I checked
all of icmp5_param_prob() usages):

--- linux-2.4.0-test10/net/ipv6/reassembly.c    Sat Jul 15 00:02:20 2000
+++ linux-2.4.0-test10.ipv6/net/ipv6/reassembly.c       Sun Nov  5 01:31:43 2000
@@ -365,7 +365,7 @@
 
        if ((unsigned int)end >= 65536) {
                icmpv6_param_prob(skb,ICMPV6_HDR_FIELD, (u8*)&fhdr->frag_off); 
-               goto err;
+               return;
        }
 
        /* Is this the final fragment? */
@@ -383,16 +383,9 @@
                 * Required by the RFC.
                 */
                if (end & 0x7) {
-                       printk(KERN_DEBUG "fragment not rounded to 8bytes\n");
-
-                       /*
-                          It is not in specs, but I see no reasons
-                          to send an error in this case. --ANK
-                        */
-                       if (offset == 0)
-                               icmpv6_param_prob(skb, ICMPV6_HDR_FIELD, 
-                                                 &skb->nh.ipv6h->payload_len);
-                       goto err;
+                       icmpv6_param_prob(skb, ICMPV6_HDR_FIELD, 
+                                         &skb->nh.ipv6h->payload_len);
+                       return;
                }
                if (end > fq->len) {
                        /* Some bits beyond end -> corruption. */

I didn't quite understand that offset == 0 test?

-- 
D.