* Chaotic structure of the net headers?
@ 2003-03-05 22:54 Adrian Bunk
2003-03-05 22:39 ` David S. Miller
2003-03-05 23:10 ` Rod Van Meter
0 siblings, 2 replies; 5+ messages in thread
From: Adrian Bunk @ 2003-03-05 22:54 UTC (permalink / raw)
To: davem, netdev; +Cc: linux-kernel
Hi,
if all I'm describing is completely logical and I'm only too dumb to see
the logic please forgive me. ;-)
In 2.5.64 there are networking headers both under include/linux/ and
include/net/. I don't understand whether there's a deeper logic why e.g.
the netfilter headers are under include/linux/.
There's some duplication, e.g. include/linux/in6.h contains
<-- snip -->
/*
* 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 */
<-- snip -->
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. */
#define NEXTHDR_ESP 50 /* Encapsulating security payload. */
#define NEXTHDR_AUTH 51 /* Authentication header. */
#define NEXTHDR_ICMP 58 /* ICMP for IPv6. */
#define NEXTHDR_NONE 59 /* No next header */
#define NEXTHDR_DEST 60 /* Destination options header. */
<-- snip -->
Two different #define's for the same thing doesn't sound like a good
idea?
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: Chaotic structure of the net headers? 2003-03-05 22:54 Chaotic structure of the net headers? Adrian Bunk @ 2003-03-05 22:39 ` David S. Miller 2003-03-05 23:10 ` Rod Van Meter 1 sibling, 0 replies; 5+ messages in thread From: David S. Miller @ 2003-03-05 22:39 UTC (permalink / raw) To: bunk; +Cc: netdev, linux-kernel From: Adrian Bunk <bunk@fs.tum.de> Date: Wed, 5 Mar 2003 23:54:41 +0100 Two different #define's for the same thing doesn't sound like a good idea? Required by the ipv6 advanced sockets API I do believe. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Chaotic structure of the net headers? 2003-03-05 22:54 Chaotic structure of the net headers? Adrian Bunk 2003-03-05 22:39 ` David S. Miller @ 2003-03-05 23:10 ` Rod Van Meter 2003-03-05 23:03 ` David S. Miller 2003-03-05 23:53 ` Richard Guy Briggs 1 sibling, 2 replies; 5+ messages in thread From: Rod Van Meter @ 2003-03-05 23:10 UTC (permalink / raw) To: ext Adrian Bunk; +Cc: davem, netdev, linux-kernel 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. > > 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). 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. 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Chaotic structure of the net headers? 2003-03-05 23:10 ` Rod Van Meter @ 2003-03-05 23:03 ` David S. Miller 2003-03-05 23:53 ` Richard Guy Briggs 1 sibling, 0 replies; 5+ messages in thread From: David S. Miller @ 2003-03-05 23:03 UTC (permalink / raw) To: Rod.VanMeter; +Cc: bunk, netdev, linux-kernel From: Rod Van Meter <Rod.VanMeter@nokia.com> Date: 05 Mar 2003 15:10:35 -0800 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. 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. Actually forget all my comments, GLIBC headers are where the advanced socket API requirements for headers should be applied. And since this is only used in the kernel, there is no need for the NEXTHDR_* if it trully just duplicates the IPPROTO_* defines. I'm willing to accept a cleanup patch of this nature, sure. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Chaotic structure of the net headers? 2003-03-05 23:10 ` Rod Van Meter 2003-03-05 23:03 ` David S. Miller @ 2003-03-05 23:53 ` Richard Guy Briggs 1 sibling, 0 replies; 5+ messages in thread From: Richard Guy Briggs @ 2003-03-05 23:53 UTC (permalink / raw) To: Rod Van Meter; +Cc: ext Adrian Bunk, davem, netdev, linux-kernel 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> ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2003-03-05 23:53 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2003-03-05 22:54 Chaotic structure of the net headers? Adrian Bunk 2003-03-05 22:39 ` David S. Miller 2003-03-05 23:10 ` Rod Van Meter 2003-03-05 23:03 ` David S. Miller 2003-03-05 23:53 ` Richard Guy Briggs
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).