Re: IPv6 fragmentation and IPv6 header parsing

[Brad Chapman <kakadu@xxxxxxxxxxxxx>]

Mr. Kuznetsov,

kuznet@xxxxxxxxxxxxx wrote:

> Hello!
>
> >       I read somewhere that the correct size for an IPv6 link was 1500.
> > Is this wrong? Is the correct MTU smaller? If it is, then sorry in
> > advance ;-)
>
>
> Yes, it is 1280. And lower MTUs are simply prohibited for IPv6 networks by law,
> it is difference of IPv4, where network can have any mtu.

  Sorry again :-( I remember reading somewhere a while ago that an IPv6 
packet was
sized around 1500, but I also remember reading online that it was 
1280....Guess I was
wrong. Sorry :-(

> IPv6 is designed specially to avoid such things. If you have some
> idea, when this can be useful, right starting point is not to hack something
> contradicting to the ideology, but to workaround this at protocol level.
>
>
> Side note: connection tracking is serious offence even for IPv4.
> I am puzzled, why the code is so primitive and forces defragmentation
> even when it is possible just to save fragments and resent them.
> This prevents f.e. usage of conntrack on routers, which need only to account.
> In fact, the most rarely happening case is considered as the most
> common one... It would be good if IPv6 did this right from the very beginning,
> rather than repeated mistakes of conntrack in IP.

  Since I didn't write the original conntrack code, I'm not sure of 
what Rusty
Russell thought when he wrote it. But, IMHO he made ip_conntrack do 
fragmentation-
on-the-fly because it would then be easier to track the guts of the 
packet, and do NAT.
Now that NAT, as we have both said, is not necessary anymore for IPv6; 
we may not
even need redirection and port forwarding either. Anyway, like I said to 
Harald,
anything regarding a system in ip6_conntrack where we save fragments and 
resend them
and/or block them, will have to wait until 2.5. For now, just make your 
MTU a proper
size and ip6_conntrack should work.
  BTW: It will probably be another month or so before ip6_conntrack is 
stable.

> Alexey
Brad