Re: Chaotic structure of the net headers?

[Richard Guy Briggs]

On Wed, Mar 05, 2003 at 03:10:35PM -0800, Rod Van Meter wrote:
> On Wed, 2003-03-05 at 14:54, ext Adrian Bunk wrote:
> > There's some duplication, e.g. include/linux/in6.h contains
> > 
> > /*
> >  *      IPV6 extension headers
> >  */
> > #define IPPROTO_HOPOPTS         0       /* IPv6 hop-by-hop options      */
> > #define IPPROTO_ROUTING         43      /* IPv6 routing header          */
> > #define IPPROTO_FRAGMENT        44      /* IPv6 fragmentation header    */
> > #define IPPROTO_ICMPV6          58      /* ICMPv6                       */
> > #define IPPROTO_NONE            59      /* IPv6 no next header          */
> > #define IPPROTO_DSTOPTS         60      /* IPv6 destination options     */
> 
> 
> According to RFC2292 (Advanced Sockets):
> 
> 2.1.1.  IPv6 Next Header Values
> 
>    IPv6 defines many new values for the Next Header field.  The
>    following constants are defined as a result of including
>    <netinet/in.h>.
> 
>    #define IPPROTO_HOPOPTS        0 /* IPv6 Hop-by-Hop options */
>    #define IPPROTO_IPV6          41 /* IPv6 header */
>    #define IPPROTO_ROUTING       43 /* IPv6 Routing header */
>    #define IPPROTO_FRAGMENT      44 /* IPv6 fragmentation header */
>    #define IPPROTO_ESP           50 /* encapsulating security payload */
>    #define IPPROTO_AH            51 /* authentication header */
>    #define IPPROTO_ICMPV6        58 /* ICMPv6 */
>    #define IPPROTO_NONE          59 /* IPv6 no next header */
>    #define IPPROTO_DSTOPTS       60 /* IPv6 Destination options */
> 
>    Berkeley-derived IPv4 implementations also define IPPROTO_IP to be 0.
>    This should not be a problem since IPPROTO_IP is used only with IPv4
>    sockets and IPPROTO_HOPOPTS only with IPv6 sockets.

The Linux FreeS/WAN IPsec implementation has been using IPPROTO_ESP, 
IPPROTO_AH, IPPROTO_INT (61, put aside by IANA for internal use),
IPPROTO_COMP (108), IPPROTO_IPIP (4) for the last 5 years, based on
common usage and examples such as IPPROTO_UDP, IPPROTO_TCP, IPPROTO_ICMP.

> > and include/net/ipv6.h contains:
> > 
> > <--  snip  -->
> > 
> > /*
> >  *      NextHeader field of IPv6 header
> >  */
> > 
> > #define NEXTHDR_HOP             0       /* Hop-by-hop option header. */
> > #define NEXTHDR_TCP             6       /* TCP segment. */
> > #define NEXTHDR_UDP             17      /* UDP message. */
> > #define NEXTHDR_IPV6            41      /* IPv6 in IPv6 */
> > #define NEXTHDR_ROUTING         43      /* Routing header. */
> > #define NEXTHDR_FRAGMENT        44      /* Fragmentation/reassembly header. */
> 
> This form doesn't appear in RFC2292, nor in 2133 (Basic Socket...)
> 
> My interpretation is that this latter form is defined for kernel use,
> while the former is for user-level manipulation of raw packet fields
> (the primary purpose of 2292).

We use these in the kernel, but not in userspace.  We define SA_ESP,
etc...

> Does it make sense to have two forms, one kernel, one user?  I haven't
> e.g. followed the desired include chain.  If we wanted to merge the
> uses, the former form and include location would probably have to be
> used.

We use the two forms since shared user/kernel headers are a nuisance...

> I've been looking into this.  There are a *few* things missing from the
> 2292 support.  AFAICT, it's just a handful of functions/macros for
> manipulating option headers that need to be added.
> 
> Does anybody actually USE this stuff (the advanced sockets API, I mean,
> not IPv6)?  I'm planning to add those missing bits, just for kicks, but
> haven't done it yet.
> 
> 			--Rod

	slainte mhath, RGB

-- 
Richard Guy Briggs           --    ~\                 Auto-Free Ottawa! Canada
<www.TriColour.net>            --    \@       @           <www.flora.org/afo/>
No Internet Wiretapping!        --   _\\/\%___\\/\%        Vote! -- <Green.ca>
<www.FreeSWAN.org>_______GTVS6#790__(*)_______(*)(*)_______<www.Marillion.com>