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

From: Brian Haberman <[email-masked]>
Date: Mon, 07 May 2012 16:00:29 -0400

All,
      I have performed the AD review for 
draft-ietf-intarea-ipv4-id-update-04.txt.  I have a few comments that I 
would like addressed before this draft proceeds...

* Section 3 states that the IPv6 fragmentation header is only present 
when a datagram has been fragmented.  Section 5 of RFC 2460 allows 
atomic fragments to carry a fragmentation header in the scenario where a 
Packet-Too-Big ICMPv6 message has been received for an MTU smaller than 
1280 and the packet is subject to translation.  This means that there 
are atomic IPv6 packets that carry a fragmentation header.

* Section 4 : I am curious as to what impact you think this document 
will have with trying to restrict the non-fragmentation use of the ID 
field.  With many of those types of tools around (and people trying to 
standardize a persistent ID for IPv6 packets), what impact will this 
document really have?

* Section 5
- 2nd paragraph : The use of the 120 second MSL value is misleading. 
First of all, the 120 seconds is specified as the MSL for TCP, not any 
other transport protocol. Secondly, my understanding is that 
implementations use RTT computations to determine when a segment has 
been lost, not a static MSL timer.  The MSL is tunable in a variety of 
implementations when they are applied to teardown states (e.g., 
TIME-WIAT).  As noted in the draft, implementations are doing something 
outside of what is specified in RFC 791 to manage their ID values and 
that is to be expected given the evolution.

- 4th paragraph : I am not aware of any routers that actually apply any 
type of time component to the management of a packet's TTL.

* Section 6 presents the classification of atomic and non-atomic packets 
in a mathematical framework.  That framework is not used anywhere else, 
so I don't see the benefit of the section.

* Section 6.1
- The discussion of SMF's use of the ID field is obsolete.  The SMF 
draft (now in the RFC Editor's queue) does not rely on the ID field for 
any of its packet identification.

- The "o  >>" notation in the lists is clumsy.  I would suggest changing 
it to strictly ">>" or some other single list icon.

* Section 6.3 tries to state the requirements defined in 791 that were 
not changed.  I do not understand why they are restated in terms of 2119 
keywords.  To me, that is imparting someone's interpretation of the 791 
rules.

* Section 8.3 discusses the updates to RFC 2003.  Why does this section 
not warrant an itemized list of changes to 2003 like the previous two 
sections that discuss changes to 791 and 1122?

Regards,
Brian

---

From: Joe Touch <[email-masked]>
Date: Mon, 07 May 2012 13:35:16 -0700

Hi, Brian,

Thanks for the feedback.

Responses below.

On 5/7/2012 1:00 PM, Brian Haberman wrote:
> when a datagram has been fragmented. Section 5 of RFC 2460 allows atomic
> fragments to carry a fragmentation header in the scenario where a
> 1280 and the packet is subject to translation. This means that there are
> atomic IPv6 packets that carry a fragmentation header.

OK - we will include a note regarding this.

> standardize a persistent ID for IPv6 packets), what impact will this

Tools that currently rely on the ID value's uniqueness are already in 
error in many cases, since the ID is not unique within the required 
period, and in some cases doesn't change at all (some mobile nets).

Part of the document's purpose, IMO, is to inform implementers - both of 
tools and stacks - on both the assumptions they should make about IDs, 
how strictly to implement ID uniqueness, and the implications of not 
doing so correctly.

This document makes no statement about the impact of IPv6 ID use, since 
it is sufficiently large that keeping it unique can require much less 
effort.

> that is to be expected given the evolution.

RFC1122 defines an MSL regarding IP reassembly. It cites RFC793 (TCP) 
for the upper bound on this value, but its discussion is not limited to 
TCP (Sec 3.3.2). This is noted the first time we cite 120 seconds, in 
the first section of the Intro (Sec 1).

I can add a reference to RFC1122 here as well if useful.

> type of time component to the management of a packet's TTL.

That paragraph already implies this; it cites RFC791 as implying the 
time component, but notes that this isn't how it's done now. Should that 
be more explicit?

> so I don't see the benefit of the section.

The sole point is to explain how these cases are tested, with an 
implication that these tests can be used in running code.

There is a pending update to clean this up and not give multiple 
versions of the same test, FWIW.

> * Section 6.1
> - The discussion of SMF's use of the ID field is obsolete. The SMF draft
> (now in the RFC Editor's queue) does not rely on the ID field for any of
> its packet identification.

OK; that will be corrected.

> it to strictly ">>" or some other single list icon.

The list icon is "o". The ">>" notation is used to highlight 
requirements where RFC2119 words are used (MUST/MAY/SHOULD/etc.), as 
explained in Sec 2.

> keywords. To me, that is imparting someone's interpretation of the 791

This was vetted by the WG, and is exactly intended to restate the 
relevant parts of RFC791 regarding the ID using RFC2119 keywords. That 
is a key part of this document.

> sections that discuss changes to 791 and 1122?

That was an oversight; we should probably include those as well.

Joe

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

---

From: Brian Haberman <[email-masked]>
Date: Tue, 08 May 2012 08:49:39 -0400

Hi Joe,
      I have snipped the portions where no further discussion is needed...

> period, and in some cases doesn't change at all (some mobile nets).

Right.  I agree that there have been tools developed assuming certain 
characteristics of the ID field.  My question is whether this document 
will have *any* impact on those tools.

> how strictly to implement ID uniqueness, and the implications of not

How many new IPv4 stacks do you expect to be implemented from this point 
forth?  How much effort do you see maintainers of current stacks putting 
into making these proposed changes?  Given the opinion expressed in 
draft-george-ipv6-support, there is some belief that this type of work 
isn't necessary.

I spent a few minutes perusing the bug reports for the Linux kernel and 
did not come across any mention of issues arising from failed 
fragmentation re-assembly, which would indicate issues with ID management.

> it is sufficiently large that keeping it unique can require much less

I understand that the draft does not change the IPv6 ID.  My point was 
to make sure people realize that there is a community of people who 
*want* to change the IPv6 ID semantics so that it is in every packet and 
their IPv4 tools can be re-used for IPv6 traffic.  Nothing to add in 
this document, just a heads-up that some people like the current 
characteristics of the IPv4 ID field.

> I can add a reference to RFC1122 here as well if useful.

That would be useful to ensure consistency.

> time component, but notes that this isn't how it's done now. Should that

Yes.  In my reading, I could not discern that implication.

> versions of the same test, FWIW.

Ok.

> requirements where RFC2119 words are used (MUST/MAY/SHOULD/etc.), as

Actually, the added list icon contradicts what is stated in Section 2 
(...the characters ">>" proceeding an indented line...).  For those 
items indicating requirements using 2119 keywords, why not just use ">>" 
as the list icon?

> is a key part of this document.

Ok.

> That was an oversight; we should probably include those as well.

Ok.

I also came across a few editorial issues...

- Section 6.2 : s/discusses that TCP retransmits a segment it/discusses 
that if TCP retransmits a segment, it/

- Section 6.2 : s/in different ways but the same/in different ways but 
with the same/

- Section 7 : s/that such more frequent reuse/that such frequent reuse/

- Section 8.2 : s/This applies both atomic and/This applies to both 
atomic and/

- Section 9 : s/including to include 4rd/including 4rd/

- Section 9 : s/comply with requirements as/comply with the requirements as/

Regards,
Brian

---

From: Joe Touch <[email-masked]>
Date: Tue, 8 May 2012 08:35:07 -0700

Hi, Brian,

>     I have snipped the portions where no further discussion is needed...

Same here.

> Right.  I agree that there have been tools developed assuming certain characteristics of the ID field.  My question is whether this document will have *any* impact on those tools.

We cannot know that in advance. Again, that's not the only reason for the doc.

> How many new IPv4 stacks do you expect to be implemented from this point forth?  How much effort do you see maintainers of current stacks putting into making these proposed changes?  Given the opinion expressed in draft-george-ipv6-support, there is some belief that this type of work isn't necessary.

That draft is relevant for IPv6; this document doesn't make statements about IPv6.

> I spent a few minutes perusing the bug reports for the Linux kernel and did not come across any mention of issues arising from failed fragmentation re-assembly, which would indicate issues with ID management.

Linux isn't the only OS on the planet, and some of the fragmentation reassembly errors might never be detected as such. They might result in more corrupt packets discarded at higher layers, or - esp. for no-checksum UDP - could result in erroneous data at the application layer. Reuse of the ID too frequently also can result in false diagnostic reports.

> I understand that the draft does not change the IPv6 ID.  My point was to make sure people realize that there is a community of people who *want* to change the IPv6 ID semantics so that it is in every packet and their IPv4 tools can be re-used for IPv6 traffic.  Nothing to add in this document, just a heads-up that some people like the current characteristics of the IPv4 ID field.

That would be useful to discuss in Intarea further. Forcing unique IDs can have a very high overhead if implemented correctly, although the IPv6 ID field is much larger than IPv4 and gives some latitude for now.

> That would be useful to ensure consistency.

Will do.

> Yes.  In my reading, I could not discern that implication.

Will fix.

> Actually, the added list icon contradicts what is stated in Section 2 (...the characters ">>" proceeding an indented line...).  For those items indicating requirements using 2119 keywords, why not just use ">>" as the list icon?

Such statements were written first - using the appropriate style - and the indenting added later. That's why some are just use >> and some include the list bullet. I can re-check to see if the list bullet can be removed in some cases where confusion would arise, such as this.

> - Section 6.2 : s/discusses that TCP retransmits a segment it/discusses that if TCP retransmits a segment, it/
> 
> - Section 6.2 : s/in different ways but the same/in different ways but with the same/
> 
> - Section 8.2 : s/This applies both atomic and/This applies to both atomic and/
> 

AOK. I'll get an update out with the two pending updates - this and the one from an area review - shortly so we can proceed.

Joe

---

From: "George, Wes" <[email-masked]>
Date: Wed, 9 May 2012 13:44:08 -0400

> > How many new IPv4 stacks do you expect to be implemented from this
> point forth?  How much effort do you see maintainers of current stacks
> putting into making these proposed changes?  Given the opinion expressed
> in draft-george-ipv6-support, there is some belief that this type of work isn't
> necessary.
>
[WEG] I disagree, and encourage you to re-read the referenced draft, along with the new charter for v4-sunset. The draft (and to some extent, charter) is asserting that IPv4 is "done" and that additional IPv4-specfic work needs to address vital operational or security issues. While I agree that a strict interpretation of ID uniqueness would be a problem, it's clear that implementers long-ago figured out that this was something to be ignored, and I'm not sure I see the utility of something that simply updates the documentation to acknowledge what everyone already knows. I can't point to other specific examples, but I'd bet that's not the only place where some of the original RFCs are being violated by best common practice and updates were never completed to correct the guidance. That said, this work predates both draft-george and v4-sunset, and I'm not making a recommendation one way or another regarding  grandfathering/completing in-flight work. I just wanted to clarify the interpretation as it relates to your draft.

> > I spent a few minutes perusing the bug reports for the Linux kernel and did
> not come across any mention of issues arising from failed fragmentation re-
> assembly, which would indicate issues with ID management.
>
> Linux isn't the only OS on the planet, and some of the fragmentation
> reassembly errors might never be detected as such. They might result in
> more corrupt packets discarded at higher layers, or - esp. for no-checksum
> UDP - could result in erroneous data at the application layer. Reuse of the ID
> too frequently also can result in false diagnostic reports.
>
[WEG] I think that the point here is that you should be identifying places where this is a real problem, and not merely a theoretical one.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Joe Touch <[email-masked]>
Date: Wed, 09 May 2012 13:58:56 -0700

On 5/9/2012 10:44 AM, George, Wes wrote:
> [WEG] I disagree, and encourage you to re-read the referenced draft,
> along with the new charter for v4-sunset. The draft (and to some extent,
> charter) is asserting that IPv4 is "done" and that additional
> IPv4-specfic work needs to address vital operational or security issues.

Sorry - I focused on the intro - which should include the IPv4 part too, 
in a future version, FWIW.

I agree with what I consider the primary focus of your draft - that V6 
issues should be required in new work (which I thought had been agreed a 
long time ago at least informally).

IMO, the IPv4 sunsetting part is poorly justified. Work in IPv6 doesn't 
come at the expense of work in IPv4, and we typically don't abandon 
protocol work unless a protocol is deemed historic (and not even then, 
AFAICT) or *harmful*.

The INTAREA WG hasn't come to this conclusion, as you note below.

> While I agree that a strict interpretation of ID uniqueness would be a
> problem, it's clear that implementers long-ago figured out that this was
> something to be ignored, and I'm not sure I see the utility of something
> that simply updates the documentation to acknowledge what everyone
> already knows. I can't point to other specific examples, but I'd bet
> that's not the only place where some of the original RFCs are being
> violated by best common practice and updates were never completed to
> correct the guidance. That said, this work predates both draft-george
> and v4-sunset, and I'm not making a recommendation one way or another
> regarding grandfathering/completing in-flight work. I just wanted to
> clarify the interpretation as it relates to your draft.

> [WEG] I think that the point here is that you should be identifying
> places where this is a real problem, and not merely a theoretical one.

The "problem" is having a requirement that most don't follow, that both 
unnecessarily constrains compliant implementations and gives a false 
sense of 'security' for both using the ID as a seed and in analysis 
equipment.

Again, this was discussed in the INTAREA WG meetings before.

Joe