lkml.org 
[lkml]   [2003]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Chaotic structure of the net headers?
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>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:33    [W:0.050 / U:0.692 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site