Subject: [Int-area] Review of draft-ietf-intarea-ipv4-id-update-02

From: Carlos Pignataro <[email-masked]>
Date: Wed, 14 Sep 2011 23:53:34 -0400

Joe, Int-area,

I had started writing a review draft-ietf-intarea-ipv4-id-update-02
sometime ago, and picked it up again late last week. Today, I noticed
rev -03 posted, but this review being almost finished I figured it would
not hurt to complete it and hit "Send".

I am hoping this is useful, and that potential issues that are already
addressed or are no longer applicable in -03 do not burn many extra
cycles. Comments grouped in more substantive and more editorial.

More Substantive:
~~~~~~~~~~~~~~~~

Abstract

   This document updates the
   specification of the IPv4 ID field in RFC 791, RFC 1122, and RFC 2003
   to more closely reflect current practice and to more closely match
   IPv6 so that the field is defined only when a datagram is actually
   fragmented.

As written, because in-flight IPv4 fragmentation is supported, does this
last statement mean that an the IP-ID of an unfragmented datagram at the
source is undefined, and takes semantics when fragmented -- potentially
in-the-network?

1. Introduction

   In IPv4, the Identification (ID) field is a 16-bit value that is
   unique for every datagram for a given source address, destination
   address, and protocol, such that it does not repeat within the
   Maximum Segment Lifetime (MSL) [RFC791][RFC1122].

Although this document is quite strict at definition of terms and
specifications, there is the assumption that MSL applies to all
datagrams (even without segments) although defined for TCP. For some
protocols the max datagram lifetime can be much smaller... As this is
attempting to modify the IP-ID at the IP Layer, is the assumption of
this MSL for everything valid?

4. Uses of the IPv4 ID Field

Should this be renamed to be qualified "Potential", "Suggested", or
"Theoretical" uses?

   The IPv4 ID field was originally intended for fragmentation and
   reassembly [RFC791]. Within a given source address, destination
   address, and protocol, fragments of an original datagram are matched
   based on their IPv4 ID. This requires that IDs are unique within the
   address/protocol triple when fragmentation is possible (e.g., DF=0)
   or when it has already occurred (e.g., frag_offset>0 or MF=1).

Similarly, this is during the max lifetime. Has the likely max lifetime
decreased? Does this update the TTL definition?

   The IPv4 ID field can also be used to validate payloads of ICMP
   responses as matching the originally transmitted datagram at a host
   [RFC4963]. In this case, the ICMP payload - an IP datagram prefix -
   is matched against a cache of recently transmitted IP headers to
   check that the received ICMP reflects a transmitted datagram. At a

"ICMP responses" or errors? In any case, I seem to recall reading
arguments against this on the basis that an ICMP generation is not time
bound, it can arrive whenever, etc.

Also RFC4963 does not discuss this particular "use".

   tunnel ingress, the IPv4 ID enables returning ICMP messages to be
   matched to a cache of recently transmitted datagrams, to support ICMP
   relaying, with similar challenges [RFC2003].

   Uses of the IPv4 ID field beyond fragmentation and reassembly require
   that the IPv4 ID be unique across all datagrams, not only when
   fragmentation is enabled. This document deprecates all such non-
   fragmentation uses.

As defined today, that is the same as for the reassembly use. IPv4-ID as
defined to be unique for the max lifetime of a datagram (RFC 791  does
not say "MSL") per src/dst/proto for all datagrams, not only for when
fragmentation is "enabled".

5. Background on IPv4 ID Reassembly Issues

   There is thus no enforcement mechanism to
   ensure that datagrams older than 120 seconds are discarded.

Doesn't this statement moots most of the document?

   throughput over LANs (e.g., disk-to-disk file transfer rates), and
   numerous throughput demonstrations have been performed with COTS
   systems over wide-area paths at these speeds for over a decade. This
   strongly suggests that IPv4 ID uniqueness has been moot for a long
   time.

Do these applications have a maximum packet lifetime of 120 seconds? Is
this demonstrating actually that the max datagram lifetime is smaller
for these?

6.1. IPv4 ID Used Only for Fragmentation

   o  >> Originating sources MAY set the IPv4 ID field of atomic
      datagrams to any value.

What is it actually gained by doing this? Things are lost though, like
the ability to use the IP-ID in debugging and troubleshooting for packet
identification by protocol analyzers and humans.

   o  >> All devices that examine IPv4 headers MUST ignore the IPv4 ID
      field of atomic datagrams.

Similarly, this is quite bold. Does Wireshark need to skip the IPv4 ID here?

   Deprecating the use of the IPv4 ID field for non-reassembly uses
   should have little - if any - impact. IPv4 IDs are already frequently
   repeated, e.g., over even moderately fast connections. Duplicate
   suppression was only suggested [RFC1122], and no impacts of IPv4 ID
   reuse have been noted. Routers are not required to issue ICMPs on any
   particular timescale, and so IPv4 ID repetition should not have been
   used for validation, and again repetition occurs and probably could
   have been noticed [RFC1812]. ICMP relaying at tunnel ingresses is
   specified to use soft state rather than a datagram cache, and should
   have been noted if the latter for similar reasons [RFC2003].

This makes a lot of sense.

6.2. Encourage Safe IPv4 ID Use

I think that these reasons and this section, as per below, are not
compelling we should not be encouraging this...

   o  >> The IPv4 ID of non-atomic datagrams MUST NOT be reused when
      sending a copy of an earlier non-atomic datagram.

The IP layer can duplicate a packet and...

   This overlap is noted as the result of reusing IPv4 IDs when
   retransmitting datagrams, which this document deprecates. Overlapping
   fragments are themselves a hazard [RFC4963]. As a result:

   o  >> Overlapping datagrams MUST be silently ignored during
      reassembly.

There are other legit reasons for overlapping datagrams, like duplicates
taking different paths...

   o  >> The IPv4 ID field of non-atomic datagrams, or protected atomic
      datagrams MUST NOT change in transit; the IPv4 ID field of
      unprotected atomic datagrams MAY be changed in transit.

Why would you allow the change for atomic datagrams? Again, what's
gained? Is there such a case that this happens today (not in a NAT)?

7. Impact on Datagram Use

   o  >> Sources of non-atomic IPv4 datagrams MUST rate-limit their
      output to comply with the ID uniqueness requirements.

I do not think this can be mandated, when a source cannot know the
maximum datagram lifetime. Certainly not in such a peanut-butter way.

   Such sources include, in particular, DNS over UDP [RFC2671].

What is the "MSL" for DNS over UDP?

   o  >> Higher layer protocols SHOULD verify the integrity of IPv4
      datagrams, e.g., using a checksum or hash that can detect
      reassembly errors (the UDP checksum is weak in this regard, but
      better than nothing), as in SEAL [RFC5320].

This seems be to an out of scope requirement as per Abstract.

   This document changes RFC 791 as follows:

   o  IPv4 ID uniqueness applies to only non-atomic datagrams.

This means that a source can set IP-ID to zero for all atomic datagrams.
Is this a better state than the current one? Protocols doing PMTUD [RFC
1191] would source atomic datagrams, and sometimes it is useful to
humans reading a packet capture to follow IP-IDs (in packets and in
headers embedded in ICMPs).

   o  Non-atomic IPv4 datagrams retransmitted by higher level protocols
      are no longer permitted to reuse the ID value.

So hosts that today do not care about the IP-ID on retransmissions, now
they need to start checking so that they do not reuse?

8.2. Updates to RFC 1122

   o  The IPv4 ID field is no longer repeatable for higher level
      protocol retransmission.

"repeatable" as in it needs to check now that it does not repeat?
Instead of relaxing, this potentially adds a requirement.

   o  IPv4 datagram fragments no longer are permitted to overlap.

This is like saying "Eclipses are no longer permitted to occur."

9. Impact on NATs and Tunnel Ingresses

   Tunnel ingresses act as sources for the outermost header, but tunnels
   act as routers for the inner headers (i.e., the datagram as arriving
   at the tunnel ingress). Ingresses can fragment as originating sources
   of the outer header, because they control the uniqueness of that IPv4
   ID field. They need to avoid fragmenting the datagram at the inner
   header, for the same reasons as any intermediate device, as noted
   elsewhere in this document.

Is this trying to implicitly abolish in-the-network IPv4 fragmentation?
For the inner header, a Tunnel ingress acts like a router, and the
Tunnel as a link. Therefore, why would it need to "avoid fragmenting the
datagram at the inner header"?

More generically, this document implies that host-only fragmentation is
the only way and flirts with abolishing intermediate frag...

10. Impact on Header Compression

I do not support this section. Seems to optimize the corner case at a
very high expense.

11. Security Considerations

   This document attempts to address the security considerations
   associated with fragmentation in IPv4 [RFC4459].

Which of the security considerations there is addressed by the changes
proposed in this document, specifically?

More Editorial:
~~~~~~~~~~~~~~

Abstract

   The IPv4 Identification (ID) field enables fragmentation and
   reassembly, and as currently specified is required to be unique
   within the maximum lifetime on all datagrams. If enforced, this
   uniqueness requirement would limit all connections to 6.4 Mbps.

Unique... for a given src/dst/proto tuple.
All connections... given the above.

   Because this is obviously not the case, it is clear that existing
   systems violate the current specification.

Is this a self-referencing statement? It is true because it is obviously
not false?

1. Introduction

   The uniqueness of the IPv4 ID is a known problem for high speed
   devices;

Do you mean "The lack of uniqueness"?

Also, is it a "known problem" or is it a "document statement"? If the
former, what is the actual problem happening in the wild?

   if strictly enforced, it would limit the speed of a single
   protocol between two endpoints to 6.4 Mbps for typical MTUs of 1500
   bytes [RFC4963].

Is an "endpoint" defined as an IPv4 address? An endpoint (as a node,
host, etc) is not really limited to this, if using multiple addresses,
limiting the max datagram lifetime for a given protocol, etc. This is a
long MSL BTW.

3. The IPv4 ID Field

   IP supports datagram fragmentation, where large datagrams are split
   into smaller components to traverse links with limited maximum
   transmission units (MTUs).

Is this tangling path vs. link MTU?

   o  In IPv6, fragments are indicated in an extension header that
      includes an ID, Fragment Offset, and MF flag similar to their
      counterparts in IPv4 [RFC2460]

In IPv6, the More Fragments is the "M flag", not the "MF flag".

5. Background on IPv4 ID Reassembly Issues

   With the maximum IPv4 datagram size of 64KB, a 16-bit ID field that
   does not repeat within 120 seconds means that the aggregate of all
   TCP connections of a given protocol between two endpoints is limited
   to roughly 286 Mbps; at a more typical MTU of 1500 bytes, this speed
   drops to 6.4 Mbps [RFC4963]. This limit currently applies for all

Same as before, "endpoint" here used as "src/dst IPv4 address pair".

6. Updates to the IPv4 ID Specification

   o  Atomic datagrams: datagrams not yet having been fragmented  (MF=0
      and fragment offset=0) and for which further fragmentation has
      been inhibited (DF=1), i.e., as a C-code expression:

Doesn't this need a license? // formality

6.3. IPv4 ID Requirements That Persist

   This document does not relax the IPv4 ID field uniqueness
   requirements of [RFC791] for non-atomic datagrams, i.e.:

   o  >> Sources emitting non-atomic datagrams MUST NOT repeat IPv4 ID
      values within one MSL for a given source address/destination
      address/protocol triple.

But RFC 791 does not talk about "MSL".

   In specific, DF=1 prevents fragmenting datagrams that are integral.
   DF=1 also prevents further fragmenting received fragments.
   Fragmentation, either of an unfragmented datagram or of fragments, is
   current permitted only where DF=0 in the original emitted datagram,
   and this document does not change that requirement.

I want to make sure I follow this logic. What does "in the original
emitted datagram" mean?

9. Impact on NATs and Tunnel Ingresses

   Network address translators (NATs) and address/port translators
   (NAPTs) rewrite IP fields, and tunnel ingresses (using IPv4
   encapsulation) copy and modify some IPv4 fields, so all are
   considered sources, as do any devices that rewrite any portion of the
   source address, destination address, protocol, and ID tuple for non-
   atomic datagrams [RFC3022]. As a result, they are subject to all the
   requirements of any source, as has been noted.

Why only non-atomic? Also, outer, and not inner, correct?

   o  >> NATs MUST ensure that the IPv4 ID field of datagrams whose
      address or protocol are translated comply with requirements as if
      the datagram were sourced by the NAT.

In which direction?

Thanks,

-- Carlos.

---

From: Joe Touch <[email-masked]>
Date: Wed, 14 Sep 2011 23:37:21 -0700

Hi, Carlos,

Thank you for the review. I've incorporated proposed changes into an 04 
update which I'll post after we converge. See notes below.

Joe

> More Substantive:

The idea is to "more closely match", not to be identical to IPv6 
semantics. Identical would require that the DF MUST be set on all 
outgoing datagrams, whether fragmented or not.

It still allows unfragmented datagrams with unique IDs and DF=0, which 
can be fragmented later.

> this MSL for everything valid?

I'm not sure what you mean when you say "max datagram lifetime can be 
much smaller" - max is the largest possible lifetime over all protocols. 
If one protocol ensures packets are discarded earlier, that's fine.

The use of MSL to define unique ID is in RFCs 791 and 1122, and not 
limited to TCP. It doesn't appear as an acronym in 791, but the text is 
  there.

The current assumptions about MSL and whether they're valid isn't really 
relevant in this paragraph - it describes how the current Internet is 
defined; the idea of maximum expected reordering is explained in this 
doc later, and is a more relevant metric for ID uniqueness.

> Should this be renamed to be qualified "Potential", "Suggested", or

This description describes all current documented uses and 
recommendations in existing RFCs. It does not recommend suggestions, nor 
is it either theoretical or potential.

> decreased? Does this update the TTL definition?

The original MSL was based on the IP TTL, which was supposed to be 
decremented by 1 for each second a router held a datagram, or by at 
least one at every router that forwarded the datagram. Although routers 
typically hold datagrams for much less than 1 second, few routers obey 
the "seconds" rule - for buffers to adjacent links that go down/come up 
(e.g., train going through a tunnel).

This document does not update TTL, nor does it update MSL.

> bound, it can arrive whenever, etc.

I've removed that section (in 04 - thought I caught that already). It 
was in originally to reflect a mechanism used in tunnels that was 
misinterpreted as caching packets (in RFC2003).

> Also RFC4963 does not discuss this particular "use".

No need to fix; the section is removed.

> fragmentation is "enabled".

Yes, that's correct. This is the current case, but that's not the idea 
the paragraph is stating; the paragraph is explaining that use beyond 
frag/reassy is putting a larger burden on the source. I'll invert the 
sentence to make that more clear.

> Doesn't this statement moots most of the document?

The document is intended to explain where existing practice is safe and 
when it is not.

Existing practice is to repeat the ID within MSL - as noted.

This is already safe when the packets are atomic. It remains unsafe (as 
it is today) when that's not the case.

The doc doesn't change what happens when MSL is incorrect, or the impact 
thereof.

> this demonstrating actually that the max datagram lifetime is smaller

This is demonstrating that the ID is being repeated in times much 
shorter than MSL as currently defined (120 seconds).

>     o>>  Originating sources MAY set the IPv4 ID field of atomic
>        datagrams to any value.
>

These are already lost, as noted above - the ID is already repeated on 
very short timescales.

This statement allows the ID to be repeated in atomic datagrams.

>     o>>  All devices that examine IPv4 headers MUST ignore the IPv4 ID

It doesn't need to skip it (it already prints out the value of other 
"MUST IGNORE" fields), but it's meaningless in those cases.

> This makes a lot of sense.

Thanks ;-)

>     o>>  The IPv4 ID of non-atomic datagrams MUST NOT be reused when

Yes, that can happen, but the datagram is already inside the network and 
subject to the MSL (presuming there's a reasonable attempt in the 
network to obey MSL). However endpoints that retransmit have no notion 
of how long that retransmission is delayed from the original datagram.

By sending the same packet into the network later, the hosts are 
themselves helping to disobey the MSL.

There's no real utility to this. If you resend a packet, if it's atomic 
then the ID doesn't matter. If it's not atomic, you should be sending it 
out with a new ID.

>     o>>  Overlapping datagrams MUST be silently ignored during
>        reassembly.
>

This section has been removed already.

>     o>>  The IPv4 ID field of non-atomic datagrams, or protected atomic

It does happen in NATs and other address sharing devices, as well as 
rewriting devices (that are neither NATs nor address sharing).

I had wanted to allow the change in atomic datagrams to reinforce the 
idea that the receiver MUST ignore it (which is a key part of this doc's 
recommendation). Others felt that this was either implied or at least 
didn't need to be stated explicitly, and it's already been removed.

>     o>>  Sources of non-atomic IPv4 datagrams MUST rate-limit their

It's already required (though widely ignored) for all datagrams today. 
This statement is just a relaxation that reminds us that we still have 
the requirement, just only for non0-atomic datagrams.

> What is the "MSL" for DNS over UDP?

The same as for all other IP datagrams - currently, 120 seconds. This is 
to call out this particular protocol as needing rate limiting, that's all.

>     o>>  Higher layer protocols SHOULD verify the integrity of IPv4

It's a recommendation based on the fact that MSL is not enforced (nor 
enforceable).

> This means that a source can set IP-ID to zero for all atomic datagrams.

Correct. FYI, this is already widely the case for some cellphones, FWIW.

> Is this a better state than the current one?

It is the current state ;-) This was raised during previous discussions 
on IP header compression, FWIW - the header compression algorithm 
recognizes fixed IDs as a special case for compression.

> Protocols doing PMTUD [RFC
> 1191] would source atomic datagrams,

They could also source non-atomic datagrams with DF=1 (i.e., that are 
source fragmented). However, even if it did source atomic datagrams 
(e.g., at the beginning of the PMTUD algorithm, when the datagrams are 
already smaller than the outgoing interface's MTU), there is no impact 
on this protocol to ignoring the ID.

 > and sometimes it is useful to

Yes, but that's already problematic (IDs repeat frequently on 
moderate-speed transfers). It can be replaced with a packet hash in some 
cases (as already noted in SMF).

> they need to start checking so that they do not reuse?

They should, yes. Like all spec changes, we assume that this cannot be 
globally corrected in legacy (existing) deployments, though.

> "repeatable" as in it needs to check now that it does not repeat?

Same as above, i.e., should not reuse the ID on datagram 
retransmissions. Which is easy to fix - set the ID when the datagram is 
emitted, and don't allow simple whole-datagram copies or buffer reuses.

> Instead of relaxing, this potentially adds a requirement.

Yes. However, it only applies to non-atomic datagrams (which will be 
clarified in 04).

> This is like saying "Eclipses are no longer permitted to occur."

The original intent was to imply that overlaps could be dropped as an 
error; the requirement about prohibiting overlaps is already removed, 
and this should have been removed in 03 too - it's gone in 04.

> Is this trying to implicitly abolish in-the-network IPv4 fragmentation?

Corrected as "avoid... unless DF=0 there" in 04. I.e., this is just 
saying to not fragment the inner packet if DF=1.

> datagram at the inner header"?

Think of ATM as an example. Should the receiver be reassembling the 
48-byte payloads, or should the other end of the ATM link?

> the only way and flirts with abolishing intermediate frag...

How tunnels are handled are different from whether intermediate 
fragmentation is allowed.

> I do not support this section. Seems to optimize the corner case at a

The discussion is important because of RFC 1144 and how it already 
handles some cases like non-changing IDs (even though those were not 
permitted at the time that RFC was published). I've added a ref to RFC 
5225 (which explains this in detail as well), esp. its section 
discussing constant IDs.

I.e., this isn't to support a new mode; the mode is already there in ROHC.

> proposed in this document, specifically?

That sentence has been removed.

The rest of the discussion is sufficient by itself.

> More Editorial:

Fixed.

> Is this a self-referencing statement? It is true because it is obviously

Reworded to be more clear in 04:

Because individual connections commonly exceed this speed, it is clear 
that existing systems violate the current specification.

> Do you mean "The lack of uniqueness"?

Uniqueness within MSL is commonly violated by...

> former, what is the actual problem happening in the wild?

(reworded). The problem, FWIW, is trying to follow the requirement.

> Is an "endpoint" defined as an IPv4 address?

Yes. I will reword to make that more clear.

> An endpoint (as a node,

MSL is defined as 120 seconds. Again, MSL is maximum over all protocols, 
under all circumstances.

E.g., consider that the maximum human lifetime may be 200 years, but 
that doesn't mean that most people live close to that long. MSL is 
intended as an ultimate upper bound.

> Is this tangling path vs. link MTU?

No. The path MTU is the min of all link MTUs, but that is not relevant 
to this description.

> In IPv6, the More Fragments is the "M flag", not the "MF flag".

Fixed.

> Same as before, "endpoint" here used as "src/dst IPv4 address pair".

Fixed.

> Doesn't this need a license? // formality

Not sure what you mean; I did reword a little (it was awkward).

>     o>>  Sources emitting non-atomic datagrams MUST NOT repeat IPv4 ID

It doesn't use the term MSL but it does talk about datagram lifetime.

> I want to make sure I follow this logic. What does "in the original

Yeah - that was confusing. Here's new 04 text:

In specific, DF=1 prevents fragmenting atomic datagrams. DF=1 also 
prevents further fragmenting received fragments. In-network 
fragmentation is permitted only when DF=0; this document does not change 
that requirement.

> Why only non-atomic?

For all datagrams; it matters for IDs only for non-atomic ones.

> Also, outer, and not inner, correct?

Tunnels copy to the outer, but sometimes modify the inner - so both. 
Since this already talks about copying and modifying, both cases are 
already covered.

>     o>>  NATs MUST ensure that the IPv4 ID field of datagrams whose

Both, but this is an issue only for the public side. On the private 
side, the destination IP address/port is changed but typically the space 
is increased (not decreased), so incoming ID uniqueness is trivial to 
ensure. I'll clarify.

----

---

From: Carlos Pignataro <[email-masked]>
Date: Thu, 15 Sep 2011 15:53:11 -0400

Hi, Joe,

Thanks for the quick response! Please find some follow-ups inline. I am
skipping some responses as they are basically the same underlying
discussion point.

> outgoing datagrams, whether fragmented or not.

I understand the "more closely match", for some value. However, my
comment is about "the field is defined only"... I am not sure I agree
with the field being not defined in the other cases. Is the field undef
for unfragmented datagrams? If not, it seems the above needs a rewrite.

> It still allows unfragmented datagrams with unique IDs and DF=0, which 

Still, since there is no "reuse", the field is _always_ defined, no?

> If one protocol ensures packets are discarded earlier, that's fine.

Sorry for not being clear, I mean that my read from RFC 791 does not
imply there is a single universal "maximum datagram lifetime" (that you
use as "MSL" from RFC793). Really not even a per protocol. The "can be
much smaller" means that if a source knows (by whichever means) that a
packet will not have a lifetime more than 10 seconds, then it can reuse
the IP-ID after that time. RFC 793 that arbitrarily defines MSL to 2
minutes also hints that a TTL influences this.

> limited to TCP. It doesn't appear as an acronym in 791, but the text is 

I mean that RFC 791 refers to the "maximum datagram lifetime", not to
MSL, and not to a defined number.

> doc later, and is a more relevant metric for ID uniqueness.

I thought it was relevant to the document as a whole, as the
Introduction is setting the stage and problem scope.

> is it either theoretical or potential.

My point was that the fact that these are documented uses, it does not
imply that they are actually implemented real uses. WIth "Uses of the
IPv4 ID Field", I understood you meant actual uses. However, the
qualifiers you use in the text are:

"The field has been suggested as a way"
"The IPv4 ID field can also be used"

As oposed to *are* used.

> (e.g., train going through a tunnel).

Tangential question, out of curiosity: since you say that 'few routers
obey the "seconds" rule', do you know of any existing ones that do, that
you can point to?

> This document does not update TTL, nor does it update MSL.

I know -- my point (sorry for not being clear) was that it basis its
updated on the assumptions of them, without analyzing those assumptions.
If a packet sets TTL to 7 in all packets, is MSL lower than 2 minutes?

> No need to fix; the section is removed.

OK, thanks.

> it is today) when that's not the case.

That's explained already in RFC 4963 -- without defining terms used here
like 'atomic packet'.

> shorter than MSL as currently defined (120 seconds).

I know. However my comment is whether a single MSL of 2 minutes as
currently defines is what match what currently happens. Or said a
different way, is it reasonable to have a maximum datagram lifetime of
120 seconds for a disk-to-disk file transfer application, and based on
that assumption claim that IPv4-ID repeats, or is it more sensible to
say that the max datagram lifetime is actually smaller and analyze the
generalized undisputed assumption of a single univeral constant MSL?

> These are already lost, as noted above - the ID is already repeated on 

I do not think they are lost. Agreed, they have less value as they
repeat, but it is more entropic than defining it as meaningless.

> themselves helping to disobey the MSL.

I do not agree with this -- for completeness only as it would not make a
huge difference.

> This section has been removed already.

OK, thanks.

> didn't need to be stated explicitly, and it's already been removed.

Makes sense. Thanks.

> to call out this particular protocol as needing rate limiting, that's all.

Sorry, I meant to imply that there are no "segments" (the S in MSL)
here, and thus highlight the over-generalization.

> emitted, and don't allow simple whole-datagram copies or buffer reuses.

My point is that this fix can still lead to ID reuse, which is what you
are forbidding. That is, hosts need to check that it is not reused, as
documented now in your requirement.

> Yes. However, it only applies to non-atomic datagrams (which will be 

OK. This seems to add another conditional requirement which adds complexity.

> and this should have been removed in 03 too - it's gone in 04.

OK. Thanks.

> saying to not fragment the inner packet if DF=1.

OK, thanks. That's not what it was saying though, so I appreciate the
clarification for -04.

> 48-byte payloads, or should the other end of the ATM link?

I do not understand this comparison. In ATM, the AAL (e.g., AAL5) would
reassemble the SDU. But connectionless IP is not ATM. If a packet with
DF=0 arrives at a router, and that datagram is to be tunneled, and the
Tunnel has a soft-state tunnel MTU that is smaller than the packet that
arrived, why can't it be fragmented at the inner header? If the host
wanted it to not be fragmented in-flight, it would have set DF.

> The rest of the discussion is sufficient by itself.

OK.

>> Same as before, "endpoint" here used as "src/dst IPv4 address pair".

Delayed-ACK/

> Not sure what you mean; I did reword a little (it was awkward).

I was asking whether using C-code components would need an explicit
simplified BSD license.

> fragmentation is permitted only when DF=0; this document does not change 

Thanks.

> is increased (not decreased), so incoming ID uniqueness is trivial to 

OK.

Thanks,

-- Carlos.

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

---

From: Joe Touch <[email-masked]>
Date: Thu, 15 Sep 2011 13:50:55 -0700

Some notes below...

It looks like we're converging. ;-)

Joe

On 9/15/2011 12:53 PM, Carlos Pignataro wrote:
...
> for unfragmented datagrams? If not, it seems the above needs a rewrite.

Yes* - that's what "ignore on receive" means.

* (for "non-atomic" - not is it not been fragmented, but DF=1 too).

> Still, since there is no "reuse", the field is _always_ defined, no?

Strictly, the field's value is defined - not that the field is 
undefined. I'll update to state that more clearly.

> minutes also hints that a TTL influences this.

MSL is a value across all possible endpoints. The only way to know the 
value is smaller is to be on a subset of the Internet - which means 
you're not on the Internet anymore (by definition), and in those cases 
almost all constants can change anyway (TTL, default window, etc.).

> MSL, and not to a defined number.

Yes, but 1122 does both.

> Introduction is setting the stage and problem scope.

The doc is to recognize existing practice as much as possible. The MSL 
hasn't changed (it's across the entire Internet), especially with the 
advent of a lot of tricks that end up delaying packets quite a lot 
(retransmission of queued packets on routers on a train after it goes 
through a tunnel, satellite links with 10's of seconds of framing, and 
even relayed ground networks - a past example was Metricom, which had 
10's of seconds of latency).

> As opposed to *are* used.

SMF uses the ID for duplicate detection and removal; I'll add that ref.

I don't know whether the ICMP validation was ever deployed, but it was 
discussed, and I thought the discussion referred to implementations 
(even though it's bad for many reasons).

So both are (AFAICT) used. I'll update the text to be more clear.

> obey the "seconds" rule', do you know of any existing ones that do, that

I know of routers that have been configured to stall their queues during 
brief outages and transmit packets after the outage - and those 
typically decrement the TTL by only one (when the packet is queued for 
output), not again upon transmission to account for the delay between 
the output queue and output link.

> If a packet sets TTL to 7 in all packets, is MSL lower than 2 minutes?

If TTL strictly meant "seconds in the net", yes, but it doesn't (as 
noted above). Any single hop can be multiples of seconds long, and the 
TTL is rarely decremented by more than one except to achieve "policy" 
(to make a link 'cost' more than another to affect routing).

...
> That's explained already in RFC 4963 -- without defining terms used here

RFC4963 talks about fragments vs. not fragments. It never talks about 
datagrams that have DF=0 that never got fragmented, nor does it talk 
about DF=1 non-fragment datagrams.

These are treated differently throughout this document, which is why we 
define the term 'atomic'.

> generalized undisputed assumption of a single univeral constant MSL?

We had text to address that in a previous version:

    o  >> Hosts emitting non-atomic IPv4 packets SHOULD NOT repeat ID
       field values within a given source IP, destination IP, and
       protocol tuple over the period that the receiver is expected to
       experience fragment reordering.

The WG decided to drop that concept, since it was not practical to 
indicate what the expected reordering interval is (I still need to 
cleanup the security considerations in the next version to remove text 
on this topic there).

> repeat, but it is more entropic than defining it as meaningless.

Some cellphones use "0" as a constant ID. That's "lost".

There are alternatives - basically to use a hash to identify packets, 
and to require upper layer protocols to have some other means to avoid 
data repetition - which they need to do anyway, since receivers are not 
required to enforce ID uniqueness over any given interval anyway.

Basically, the ID never meant anything outside fragmentation. Yes, this 
could have impact on debugging equipment (which I'll add text to 
discuss), but that should be fixed anyway IMO.

...
> I do not agree with this -- for completeness only as it would not make a

The problem is that if we continue to allow ID reuse for 
retransmissions, the host has additional requirements to find a way to 
make the datagram expire more quickly inside the network. There's no way 
to achieve this - as noted above a TTL change won't help. There's also 
no real need to do this - the ID can (and should) be set when the packet 
is transmitted, not cached anyway.

Do we need more text to explain this?

...
> here, and thus highlight the over-generalization.

Hmm. We typically call transport data units "segments" to differentiate 
them from network layer (datagrams). UDP strictly allows users to 
present datagrams at the transport layer, but I'm still referring to 
them here as segments.

Would you prefer "MPL" - maximum protocol-data-unit lifetime? or can you 
suggest an alternative?

...
> documented now in your requirement.

Oh - sorry. This requirement is intended to repeat the "don't retransmit 
with the same ID", not "don't use this ID for a new packet within 2MSL".

I will reword in 04.

> OK. This seems to add another conditional requirement which adds complexity.

It's not new - again, I'll reword.

...
> arrived, why can't it be fragmented at the inner header?

It can (if DF=0) - the correction above fixes this already.

> If the host

Yes - again, the update fixes this now.

There are other reasons not to do this, though.

The pros and cons are discussed in the tunnel-id, and in SEAL RFCs, but 
we don't need to include that here.

...
>>> More Editorial:
...
>>> Same as before, "endpoint" here used as "src/dst IPv4 address pair".

Can you clarify this? They delayed ACK isn't the problem; the data 
segments are.

> I was asking whether using C-code components would need an explicit

I'm expressing it in C-like notation (I can say "C-like").

It's not intended as running code, nor is it presented as such.

---

---

From: Joe Touch <[email-masked]>
Date: Thu, 15 Sep 2011 15:08:44 -0700

Regarding the impact of ignoring the ID field on debugging:

On 9/15/2011 1:50 PM, Joe Touch wrote:
> Yes, this could have impact on debugging equipment (which I'll add text
> to discuss), but that should be fixed anyway IMO.

I've added 04 text to explain that IPv6 debugging can't rely on the ID, 
so removing that feature from IPv4 debugging can be handled similarly.

Joe

---

From: Carlos Pignataro <[email-masked]>
Date: Fri, 16 Sep 2011 09:50:57 -0400

Joe,

> so removing that feature from IPv4 debugging can be handled similarly.

Thanks for acknowledging the use on debugging. I agree with you, I think
it is a tool issue:
http://www.ietf.org/mail-archive/web/v6ops/current/msg10259.html
http://www.ietf.org/mail-archive/web/v6ops/current/msg10266.html

But explaining the current use explicitly would help.

Thanks,

-- Carlos.

---

From: Carlos Pignataro <[email-masked]>
Date: Fri, 16 Sep 2011 09:55:06 -0400

Hi, Joe,

Thanks much again for the quick set of responses, and for the proposed
changes. Seems much of it is covered, and there's potentially still some
areas of disagreement; I'll review -04 when you post it.

Thanks again,

-- Carlos.