Subject: [Int-area] Recycle IPv4 bits

From: Teco Boot <[email-masked]>
Date: Thu, 31 Mar 2011 13:41:03 +0200

Having a discussion on recycling used IPv4 header bits, I made
a snapshot on what was in the air at same point in time, somewhere.
I found out the ID field of atomic packets was filled for almost
all packets.

IPv4 total:      151081
Atomic packets:  105357 (70%)
On atomic packets:
  ID == 0     1557 (  1,5%)
  ID != 0   103800 ( 98,5%)
  FO == 0   105357 (100,0%)

The Fragment Offset was always set on zero, I read this as unused. 
What comes up in my mind: can we recycle the 13 fragment offset bits? 
Instead of ID field? At least it may be a well defined starting point.

Teco

---

From: Thomas Narten <[email-masked]>
Date: Thu, 31 Mar 2011 14:23:11 +0200

IMO, this effort is a distractoin and poor use of IETF cycles.

There is hardly any compelling need to find unused bits, especially
given that any reuse of such bits will be fraught with risks and
deployability issues. They won't be useable in practice. (Just look at
how hard it is to deploy anything new, like IP options.)

And to the point, what important problem would this solve?

We have so many *real* problems that are in need of solutions and
critical thinking. Why do we find the need to spend any time on topics
for which there is no compelling problem in need of solving and for
which eventually deployment seems remote (at best)?

We are here to make the Internet Work Better. Can we please focus our
(precious and limited) energy on topics where we actually have a
realistic chance of making difference in practice?

Thomas

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 31 Mar 2011 14:30:49 +0200

> Instead of ID field? At least it may be a well defined starting point.

No. 

When I was implementing fragment reassembly for DOS NCSA Telnet back in ~1992 I found that several systems (4.3bsd among them, IIRC) took the shortcut of NOT setting the is-fragmented bit if the fragment offset was non-zero.

Thus to do reassembly correctly required assuming you were looking at a fragment any time fragment offset != 0.

Matthew Kaufman

(Sent from my iPhone)

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 31 Mar 2011 14:57:07 +0200 (CEST)

> how hard it is to deploy anything new, like IP options.)

... or for how many years ECN was unusable due to firewalls dropping 
packets with those bits set.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 31 Mar 2011 06:01:33 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Mikael Abrahamsson
> Sent: Thursday, March 31, 2011 5:57 AM
> To: Thomas Narten
> Cc: [email-masked]
> Subject: Re: [Int-area] Recycle IPv4 bits
> 

I tried to get the Evil bit for PMTUD a few years ago, but
didn't get any traction. I think Bob Briscoe wanted it for
Re-ECN a while back, but in his presentation on Tuesday it
sounded like he was asking for it for a different purpose
now. Has this all been a waste of time?

Thanks - Fred
[email-masked]

---

From: Xiangsong Cui <[email-masked]>
Date: Thu, 31 Mar 2011 21:31:29 +0800

Hi Teco,

I have this idea, too, and I ever had some off-list discussion with Joe and Bob.
Because there is only one reserved bit in IPv4 header now, so I think it is better to resolve it together, with the fragment ID field (they are both fragement related fields).

We have only one jeton, should we use it to get a bigger production?

Best Regards
Xiangsong

----- 原邮件 -----
发件人: Teco Boot <[email-masked]>
日期: 星期四, 三月 31日, 2011 下午9:20
主题: [Int-area] Recycle IPv4 bits
收件人: [email-masked]

> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
>

---

From: <[email-masked]>
Date: Thu, 31 Mar 2011 17:20:20 +0000

Thomas,

This is the question I have had in my mind but have been afraid to ask.

I think we should drop this topic.

Cheers,

Jonne.
-- 
Jonne Soininen
Renesas Mobile

Tel: +358 40 527 4634
E-mail: [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Thu, 31 Mar 2011 10:45:04 -0700

Hi, Deco,

This proposal is a moot point; the FO needs to be zero for a packet to 
be ATOMIC. see below:

> The Fragment Offset was always set on zero, I read this as unused.

That is incorrect. It is part of what makes a packet atomic, as per the 
ipv4-id-update draft:

	(DF==1)&&(MF==0)&&(frag_offset==0)

Let's look at the cases:

DF MF FO
0  x  x  	CAN FRAGMENT
		non-atomic packet that can be fragmented downstream;
		that fragmentation would overwrite MF and FO

1  0  0		ATOMIC		
		basically this is a lot like saying
		"this is the first and last fragment"

1  0  nonzero	LAST FRAGMENT
		packet has already been fragmented and
		this is the last fragment

1  1  0		FIRST FRAGMENT
		packet has already been fragmented, and this is the
		first fragment and NOT the last (other fragments
		with higher offsets are expected)

1  1  nonzero	MIDDLE FRAGMENT
		packet has already been fragmented, and this is
		not the first fragment, and other fragments are
		expected

Note that thus:

	ATOMIC packets are *defined* by having all the FO bits as zero.

 > Instead of ID field? At least it may be a well defined starting point.

When the bits aren't zero, an otherwise ATOMIC packet is really a last 
fragment.

So if you try to use those bits, all you will accomplish is flooding the 
reassembly cache.

Joe