Subject: Re: Comments on 2292bis (Adv. API)

From: Tim Hartrick <[email-masked]>
Date: Fri, 3 Sep 1999 00:02:42 -0700 (PDT)

Jinmei,

> 
> ============
> Router Renumbering related structures:
> #if BYTE_ORDER == BIG_ENDIAN /* net byte order */
> struct icmp6_router_renum {	/* router renumbering header */
> 	struct icmp6_hdr	rr_hdr;
> 	u_int8_t		rr_segnum;
> 	u_int8_t		rr_test : 1;
> 	u_int8_t		rr_reqresult : 1;
> 	u_int8_t		rr_forceapply : 1;
> 	u_int8_t		rr_specsite : 1;
> 	u_int8_t		rr_prevdone : 1;
> 	u_int8_t		rr_flags_reserved : 3;
> 	u_int16_t		rr_maxdelay;
> 	u_int32_t		rr_reserved;
> };
> #elif BYTE_ORDER == LITTLE_ENDIAN
> struct icmp6_router_renum {	/* router renumbering header */
> 	struct icmp6_hdr	rr_hdr;
> 	u_int8_t		rr_segnum;
> 	u_int8_t		rr_flags_reserved : 3;
> 	u_int8_t		rr_prevdone : 1;
> 	u_int8_t		rr_specsite : 1;
> 	u_int8_t		rr_forceapply : 1;
> 	u_int8_t		rr_reqresult : 1;
> 	u_int8_t		rr_test : 1;
> 	u_int16_t		rr_maxdelay;
> 	u_int32_t		rr_reserved;
> };
> #endif /* BYTE_ORDER */
>

If I am remembering my ANSI C correctly there are a couple of problems
with definitions which make use of bitfields.

First, the ANSI standard does not support the declaration of bitfields based
on any type other than  unsigned int.

Secondly, the implementation of bitfields is allowed to vary substantially
from one compiler and/or architecture to another.  Some compilers for some
architectures may choose to pack bitfields in a way that would make both the
above definitions useless regardless of byte order.

If this specification is to be portable I believe that we will need to define
structures in a way that does not run afoul of the architecturally flexible
parts of the ANSI C language standard.

Lastly, ignoring the possible portability problems, some compilers generate
code for bitfield operations which performs really poorly relative to code
that uses scalar types and bit operators.  Based on this alone I would recommend
that we not attempt to use bitfields.

Tim Hartrick

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 03 Sep 1999 21:58:41 +0900

>>>>> On Fri, 3 Sep 1999 00:02:42 -0700 (PDT), 
>>>>> Tim Hartrick <[email-masked]> said:

> that we not attempt to use bitfields.

Though currently I don't have a way to access ANSI C specification,
your comment seems reasonable. Actually, we had a discussion in the
KAME team that we could safely use bitfields, but I forgot the
consensus.

I personally agree with you; we shouldn't use bitfields (especially
for packet formats) if we regard portability.

I'll confirm the opinion of the author of the structures for router
renumbering.

Thanks,

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Yoshinobu Inoue <[email-masked]>
Date: Fri, 10 Sep 1999 12:06:08 +0900

> I'll confirm the opinion of the author of the structures for router

After the KAME team and WIDE group discussion, we decided to
change the structure not to use bitfields.

This is a revised proposal of router renum packet
structure. Comments are welcome.

Yoshinobu Inoue

struct icmp6_router_renum {	/* router renumbering header */
	struct icmp6_hdr	rr_hdr;
	u_int8_t		rr_segnum;
	u_int8_t		rr_flags;
	u_int16_t		rr_maxdelay;
	u_int32_t		rr_reserved;
};
#define ICMP6_RR_FLAGS_SEGNUM		0x1
#define ICMP6_RR_FLAGS_TEST		0x2
#define ICMP6_RR_FLAGS_REQRESULT	0x4
#define ICMP6_RR_FLAGS_FORCEAPPLY	0x8
#define ICMP6_RR_FLAGS_SPECSITE		0x10
#define ICMP6_RR_FLAGS_PREVDONE		0x20

#define rr_type			rr_hdr.icmp6_type
#define rr_code			rr_hdr.icmp6_code
#define rr_cksum		rr_hdr.icmp6_cksum
#define rr_seqnum 		rr_hdr.icmp6_data32[0]

struct rr_pco_match {		/* match prefix part */
	u_int8_t	rpm_code;
	u_int8_t	rpm_len;
	u_int8_t	rpm_ordinal;
	u_int8_t	rpm_matchlen;
	u_int8_t	rpm_minlen;
	u_int8_t	rpm_maxlen;
	u_int16_t	rpm_reserved;
	struct in6_addr	rpm_prefix;
};

#define RPM_PCO_ADD		1
#define RPM_PCO_CHANGE		2
#define RPM_PCO_SETGLOBAL	3

struct rr_pco_use {		/* use prefix part */
	u_int8_t	rpu_uselen;
	u_int8_t	rpu_keeplen;
	u_int8_t	rpu_ramask;
	u_int8_t	rpu_raflags;
	u_int32_t	rpu_vltime;
	u_int32_t	rpu_pltime;
	u_int32_t	rpu_flags;
	struct in6_addr rpu_prefix;
};
#define ICMP6_RR_PCOUSE_RAFLAGS_ONLINK		0x1
#define ICMP6_RR_PCOUSE_RAFLAGS_AUTO		0x2

#if BYTE_ORDER == BIG_ENDIAN
#define ICMP6_RR_PCOUSE_FLAGS_DECRVLTIME	0x80000000
#define ICMP6_RR_PCOUSE_FLAGS_DECRPLTIME	0x40000000
#elif BYTE_ORDER == LITTLE_ENDIAN
#define ICMP6_RR_PCOUSE_FLAGS_DECRVLTIME	0x80
#define ICMP6_RR_PCOUSE_FLAGS_DECRPLTIME	0x40
#endif

struct rr_result {		/* router renumbering result message */
	u_int16_t	rrr_flags;
	u_int8_t	rrr_ordinal;
	u_int8_t	rrr_matchedlen;
	u_int32_t	rrr_ifid;
	struct in6_addr rrr_prefix;
};
#if BYTE_ORDER == BIG_ENDIAN
#define ICMP6_RR_RESULT_FLAGS_OOB		0x0002
#define ICMP6_RR_RESULT_FLAGS_FORBIDDEN		0x0001
#elif BYTE_ORDER == LITTLE_ENDIAN
#define ICMP6_RR_RESULT_FLAGS_OOB		0x02
#define ICMP6_RR_RESULT_FLAGS_FORBIDDEN		0x01
#endif

---

From: Yoshinobu Inoue <[email-masked]>
Date: Fri, 10 Sep 1999 15:09:56 +0900

#I resend this message because there seemed to be some mail error.
#Sorry for anyone getting this mail twice.

Yoshinobu Inoue

#define RPM_PCO_ADD          1
#define RPM_PCO_CHANGE          2

---

From: "Matt Crawford" <[email-masked]>
Date: Fri, 10 Sep 1999 09:23:08 -0500

Either I'm confused, or these are a little mixed-up.  I don't know
what the first one is, and I would expect the others to have values
0x80, 0x40, 0x20, 0x10, 0x08 in that order.

(I just tuned in to this thread and may have missed some key
information.)
				Matt

---

From: Yoshinobu Inoue <[email-masked]>
Date: Sat, 11 Sep 1999 00:48:52 +0900

> 0x80, 0x40, 0x20, 0x10, 0x08 in that order.

Sorry, several parts of the bit order was very confusing.
I should have reviewed more before sending it.
This is fixed version.

struct icmp6_router_renum {	/* router renumbering header */
	struct icmp6_hdr	rr_hdr;
	u_int8_t		rr_segnum;
	u_int8_t		rr_flags;
	u_int16_t		rr_maxdelay;
	u_int32_t		rr_reserved;
};
#define ICMP6_RR_FLAGS_TEST		0x80
#define ICMP6_RR_FLAGS_REQRESULT	0x40
#define ICMP6_RR_FLAGS_FORCEAPPLY	0x20
#define ICMP6_RR_FLAGS_SPECSITE		0x10
#define ICMP6_RR_FLAGS_PREVDONE		0x08

#define RPM_PCO_ADD		1
#define RPM_PCO_CHANGE		2

struct rr_pco_use {		/* use prefix part */
	u_int8_t	rpu_uselen;
	u_int8_t	rpu_keeplen;
	u_int8_t	rpu_ramask;
	u_int8_t	rpu_raflags;
	u_int32_t	rpu_vltime;
	u_int32_t	rpu_pltime;
	u_int32_t	rpu_flags;
	struct in6_addr rpu_prefix;
};
#define ICMP6_RR_PCOUSE_RAFLAGS_ONLINK		0x20
#define ICMP6_RR_PCOUSE_RAFLAGS_AUTO		0x10

---

From: Yoshinobu Inoue <[email-masked]>
Date: Mon, 13 Sep 1999 12:09:19 +0900

Sorry, there is still a bug in router renum structure proposal.
(Thanks for Francis Dupont for checking this.)

struct rr_result {		/* router renumbering result message */
	u_int16_t	rrr_flags;
	u_int8_t	rrr_ordinal;
	u_int8_t	rrr_matchedlen;
	u_int32_t	rrr_ifid;
	struct in6_addr rrr_prefix;
};
#if BYTE_ORDER == BIG_ENDIAN
#define ICMP6_RR_RESULT_FLAGS_OOB		0x0002
#define ICMP6_RR_RESULT_FLAGS_FORBIDDEN		0x0001
#elif BYTE_ORDER == LITTLE_ENDIAN
-#define ICMP6_RR_RESULT_FLAGS_OOB		0x02
-#define ICMP6_RR_RESULT_FLAGS_FORBIDDEN	0x01
+#define ICMP6_RR_RESULT_FLAGS_OOB		0x0200
+#define ICMP6_RR_RESULT_FLAGS_FORBIDDEN	0x0100
#endif

Yoshinobu Inoue