Subject: [Int-area] FW: New Version Notification for draft-george-ipv6-required-02.txt

From: "George, Wesley" <[email-masked]>
Date: Wed, 1 Jun 2011 10:47:52 -0400

After the discussion of this draft in Prague and with the WG chairs and ADs, we have updated it to address a few comments, but primarily to remove the language directing IETF action. This limits the draft to simply requiring IPv6 for IP-capable devices, and should address the concern about whether it interferes with existing WG actions as well as the recommendation that normally IETF action directions are done via BCP rather than standards-track documents.

We would like to ask for formal WG adoption of this draft, as well as reviews to see if it can soon be made ready for WGLC (assuming WG adoption is successful).
http://tools.ietf.org/html/draft-george-ipv6-required-02

Any discussion about IETF's response to this draft (in terms of how WGs operate, their charters, etc) will be issued in a separate BCP draft. Right now, we want to focus on getting this draft out so that it can provide guidance to IPv6 implementors.

Thanks!

Wes George and co-authors.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, June 01, 2011 10:30 AM
To: George, Wesley
Cc: Howard, Lee; Donley, Chris (Cable Labs); George, Wesley; [email-masked]
Subject: New Version Notification for draft-george-ipv6-required-02.txt

A new version of I-D, draft-george-ipv6-required-02.txt has been successfully submitted by Wesley George and posted to the IETF repository.

Filename:        draft-george-ipv6-required
Revision:        02
Title:           IPv6 Support Required for all IP-capable nodes
Creation date:   2011-06-01
WG ID:           Individual Submission
Number of pages: 7

Abstract:
   Given the global lack of available IPv4 space, and limitations in
   IPv4 extension and transition technologies, this document deprecates
   the concept that an IP-capable node MAY support IPv4 _only_, and
   redefines an IP-capable node as one which supports either IPv6 _only_
   or IPv4/IPv6 dual-stack.  This document updates RFC1812, 1122 and
   4084 to reflect the change in requirements.

The IETF Secretariat

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: Julien Laganier <[email-masked]>
Date: Wed, 1 Jun 2011 13:48:16 -0700

Folks,

At this point we' d like to ask WG participants whether or not there
is interest in adopting this document as intarea WG draft. Please
express your opinions on the mailing list.

--julien & scott

On Wed, Jun 1, 2011 at 7:47 AM, George, Wesley
<[email-masked]> wrote:
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
>

---

From: Alain Durand <[email-masked]>
Date: Wed, 1 Jun 2011 18:51:08 -0700

> express your opinions on the mailing list.

Julien,

I believe the wg should not adopt this document.

The core rationale of this document seems to be here:
"   However, the IPv6 deployment necessary to reduce reliance on IPv4 has
   been hampered by a lack of ubiquitous hardware and software support
   throughout the industry.  Many vendors, especially in the consumer
   space have continued to view IPv6 support as optional.?

I do not work for one of those "consumer space vendor" that has not done its IPv6 homework,
but I very often say those same vendors saying: there is no demand... sending the ball back into the customers
court or the ISPs court or the content providers court.  At this point, my argument is that:
a) pointing fingers is not going to help.
b) The IETF is very good at defining standards. The IETF has very little say in what goes in the actual POs.

Then the document goes on requiring that:
"   Updates [RFC1122
    to redefine generic "IP" support to include and
   require IPv6 for IP-capable nodes and routers."

So, If a vendor is building an IPv4 NAT for an IPv4-only provider, it needs to add IPv6 in there?
This is adding unnecessary code and effort that the vendor. Such effort would have been better
spent to do actual useful IPv6 work.

Later:
"      Current and new IP Networking implementations SHOULD support IPv4
      and IPv6 coexistence (dual-stack), but MUST NOT require IPv4 for
      proper and complete function."

Nice goal, but in practice, for most devices, we are a very long way from an IPv6-only operation.
Example: 6PE. Very well understood, very useful to get IPy6 deployed quickly in a backbone.
Under the proposed text, 6PE could not be standardized.
Another example: SNMP. Most backbones, with few exceptions, are dual-stacked. On those backbones,
SNMP data can be retrieved on IPv4. Yes, doing this over IPv6 is possible, but is it really necessary?
Wouldn't the resources be spent better elsewhere?

	- Alain.

---

From: "George, Wesley" <[email-masked]>
Date: Thu, 2 Jun 2011 10:29:13 -0400

-----Original Message-----
From: Alain Durand [mailto:[email-masked]]
Sent: Wednesday, June 01, 2011 9:51 PM
Subject: Re: [Int-area] FW: New Version Notification for draft-george-ipv6-required-02.txt

Julien,

I do not work for one of those "consumer space vendor" that has not done its IPv6 homework,
but I very often say those same vendors saying: there is no demand... sending the ball back into the customers
court or the ISPs court or the content providers court.

WEG> are we really going to try to even partially blame the lack of IPv6 deployment on content providers? Chicken, egg, I'd like to introduce you both to World IPv6 Day. Content providers and ISPs are both taking the necessary steps to support IPv6. It may not be on the timeline we'd all like, but it's happening. But fat lot of good it does anyone if IPv6 is still not supported in the devices that would need to consume that content.

AD>  At this point, my argument is that:
a) pointing fingers is not going to help.

WEG> Alain, if you believe this to be pointing fingers, I'd first refer you to your comments above about whose court the ball is in, and second, request that you propose text that resolves the issue. However, I don't view a frank discussion of the current problem facing wider IPv6 deployment as pointing fingers. It's not as if it's a list of offending vendors.

AD> b) The IETF is very good at defining standards. The IETF has very little say in what goes in the actual POs.

WEG> The problem, as I and others have said repeatedly when discussing this draft is that the ISPs don't control the POs either. Maybe for the CPE GW, but not in all cases, and definitely not the customer's TV, internet-capable refrigerator, gaming console, AV receiver, Blu-Ray player, etc. And customers have no reason at this point to specifically request IPv6 support when they walk into their local big-box retailer. Even if they did, how will that actually translate upward into a product decision? It's not as if there's exit polls asking why you chose one device over another.
If the average consumer even knows what IPv6 is, we've failed at making the transition, because it's not a feature any more than IPv4 is a feature. "Internet connectivity" is a feature. Which version of the protocol is being used is a technical implementation detail of that feature that should be transparent to the user. The argument that this is a problem of ISPs and consumers not putting their money where their mouths are is nonsense.
This document is aimed at giving updated guidance to the folks who use IETF standards as guidelines for their implementations that IPv4 and IPv6 are no longer two options that can be chosen independently, because it is simply not sustainable to expect IPv4 to suffice on its own anymore. It is one (missing) part of a growing chorus of folks trying to fix the places where IPv6 support is lacking, but to have the primary Internet standards body continue to ignore the fact that IPv4 growth is unsustainable and IPv6 is no longer optional is IMHO as bad or worse than those refusing to implement because there is "no demand." We [the IETF] should know better.

AD> Then the document goes on requiring that:
"   Updates [RFC1122
    to redefine generic "IP" support to include and
   require IPv6 for IP-capable nodes and routers."

WEG> I'm starting to think that you're purposely misinterpreting this document in order to make it seem like a bad idea, but I'm not sure why that would be...
The IETF isn't the protocol police, and they're not a certification organization. Ultimately, what a vendor builds for a provider, including what standards they choose to follow, ignore, or tweak is entirely between that vendor and whomever is writing the checks. Our standards are for guidance. However, if any vendor is hanging their long-term business model on being able to continue providing IPv4-only devices for IPv4-only providers, I'd strongly recommend selling their stock, and I don't view this as a valid example of why the draft is harmful.

AD> Later:

WEG> Yet you're maintaining that a document making this the direction that IETF should head is somehow wrong. How are we ever going to fix it if we don't start moving in that direction?

AD> Example: 6PE. Very well understood, very useful to get IPy6 deployed quickly in a backbone.
Under the proposed text, 6PE could not be standardized.

WEG> No, that's simply incorrect. This document no longer makes any recommendations as to how the IETF should apply this to WG charters or protocols and proposed standards. That interpretation remains the IESG's responsibility. The text that I removed after your and others concerns about that being in a standards document instead of a BCP specifically discussed this, and more importantly, specifically referred to transition technologies being exempt from the directive to stop working on IPv4-only protocol development. I'm not opposed to trying to add some clarification here specifically regarding transition technologies, but I think you are again exaggerating the issue, and would like to see some other folks weigh in on whether this is indeed a problem with the current language.

AD> Another example: SNMP. Most backbones, with few exceptions, are dual-stacked. On those backbones,
SNMP data can be retrieved on IPv4. Yes, doing this over IPv6 is possible, but is it really necessary?

WEG> I see nowhere that this document requires *operators* to use IPv6 for SNMP (or for anything, really). This is a document for implementers aimed at providing maximum flexibility as to how the operator chooses to implement by ensuring that the devices and software support IPv6 as completely as possible. The reality is that single-stack IPv6 networks do exist, and will become more prevalent as IPv4 exhausts completely. And while an operator may choose not to use IPv6 for SNMP today, my vendor damn well better have support for it in case I choose to move to a single-stack backbone tomorrow. I can think of several reasonable cases for moving to IPv6 for management that were stymied by exactly these types of erroneous assumptions. That is, discussions that I was part of in, you know, an actual operator network, where we had to figure out a workaround because missing IPv6 support for certain features meant that we couldn't do the simplest thing, which was to move to IPv6 to avoid an IPv4 address constraint.

AD> Wouldn't the resources be spent better elsewhere?

WEG> Unless you can provide some actual concrete examples, I'm going to view this as a rhetorical question, asked because you don't actually have a legitimate problem and are merely trying to spread FUD. If it is as you say and we're a long way from being able to properly run an IPv6-only network, I'd say that's one of IETF's larger priorities. We're 16 years in, and you're saying that the protocol still isn't done? That's a pretty long time, even by IETF standards. There don't need to be any additional barriers for IPv6 adoption. The existing financial and resource constraints are already more than enough. If "IPv6 still doesn't do X, and I can do that on IPv4, so I can't move to IPv6" is still a valid excuse, we need to be fixing that.

Wes George

---

From: Warren Kumari <[email-masked]>
Date: Thu, 2 Jun 2011 13:17:39 -0400

> We would like to ask for formal WG adoption of this draft, as well as reviews to see if it can soon be made ready for WGLC (assuming WG adoption is successful).

I firmly support adoption of this draft....

(I don't necessarily think it is going to change things much, but I believe that it is worth adopting and giving it try...)

W

---

From: Benson Schliesser <[email-masked]>
Date: Thu, 02 Jun 2011 13:04:17 -0500

On 6/2/11 9:29 AM, "George, Wesley" <[email-masked]> wrote:

> WEG> The problem, as I and others have said repeatedly when discussing this
> draft is that the ISPs don't control the POs either. Maybe for the CPE GW, but
> not in all cases, and definitely not the customer's TV, internet-capable
> refrigerator, gaming console, AV receiver, Blu-Ray player, etc.

I find myself largely agreeing with Alain's comments, but also agreeing with
the goal of this draft.  Call me "undecided" if you wish.

I suppose that my fundamental question is this: what, pragmatically, would
this draft achieve that existing RFCs do not?  After all, an RFC is just an
RFC - there is no mandatory compliance, enforcement, etc; support for IETF
standards and best-practices is completely voluntary and unaudited (until in
one's lab).

So, if published, would a vendor simply say "yeah we're compliant with
RFC-ipv6-required" along with all the other IPv6 RFCs?  Or do you imagine
that they'll be forced to stop claiming compliance with 1812, 1122, and
4084?  If the market is (or isn't) going to push us to IPv6, what effect do
you imagine this draft will have on things?

Thanks,
-Benson

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 03 Jun 2011 10:41:18 +1200

I've seen the counter arguments, but I think this draft, or at least
the principle it embodies, is welcome and *long* overdue.

We shouldn't be spending any effort on polishing the IPv4 heirloom,
except for vital security or operational fixes.

Regards
   Brian Carpenter

---

From: Alain Durand <[email-masked]>
Date: Thu, 2 Jun 2011 16:32:48 -0700

> except for vital security or operational fixes.

Brian,

I would have agreed if IPv6 was a direct replacement of IPv4. Unfortunately, it is not the case.

  - Alain.

---

From: Jared Mauch <[email-masked]>
Date: Thu, 2 Jun 2011 19:53:39 -0400

I support adoption of this draft as well.

- Jared Mauch

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 02 Jun 2011 21:30:33 -0400

> except for vital security or operational fixes.

I agree with this 100%.

-- 
Wes Eddy
MTI Systems

---

From: Ed Jankiewicz <[email-masked]>
Date: Fri, 03 Jun 2011 09:33:51 -0400

I support advancing this draft and agree that making IPv6 "the new 
normal" is philosophically a good idea.

The effort expended to "polish the heirloom" as Brian put it, has been 
in good faith by people who have a vested interest in making the best of 
the current situation (keeping IPv4 working in the face of many more end 
points than its designers ever planned for) and this will continue as 
long as IPv6 is not seen as a viable alternative.  It will not achieve 
that until it sees wide deployment and starts to carry a significant 
slice of the packets.  Only then will the energy shift to making IPv6 
better rather than keeping IPv4 going.

We'll park the heirloom in the garage, and roll it out for special 
occasions (i.e. there will be a very long tail for IPv4 legacy usage for 
many situations) but enjoy driving and polishing the shiny new V6 muscle 
car.

Ed J.

---

From: "George, Wesley" <[email-masked]>
Date: Fri, 3 Jun 2011 13:38:11 -0400

-----Original Message-----
From: Benson Schliesser [mailto:[email-masked]]
Sent: Thursday, June 02, 2011 2:04 PM
To: George, Wesley; Alain Durand; Julien Laganier
Subject: Re: [Int-area] FW: New Version Notification for draft-george-ipv6-required-02.txt

WEG> Well, as you've said, compliance with an RFC is often open to interpretation. It would be an interesting side-effect that some folks would decide that some devices would no longer be compliant with the above-referenced RFCs, but that wasn't specifically the aim of the draft.
As I've said, I realize that the IETF is not the protocol police, and we have little say over what an implementer actually chooses to do. However - we make recommendations in our standards all day every day with words like MUST, SHOULD, etc, and we expect that implementers will mostly follow those recommendations, since they are based on a certain set of rationale, either experimental or philosophical. I'm having trouble understanding why a recommendation/requirement to support IPv6 in "IP-capable" devices is being held to a higher standard of relevance/impact than, say, deprecating MD5 for securing BGP sessions, something that is also still in wide use, but has a known flaw and whose replacement is still not widely supported.
There have been prior discussions about simply declaring IPv4 historic and being done with it, but most folks I talked to agreed that this draft made sense as a first step on that road. IETF has thus far remained fairly neutral about IPv6 vs IPv4 - you can do one, you can do the other, you can do both, we don't care. It has been similar to when we have two or more equally acceptable, standardized ways of solving the same problem - one is not preferred over the other, and each application will have to consider the pros and cons of both options. However, at some point if the second solution is found to have a flaw or something that makes the first a better choice, we often update our guidance to say that one is "considered harmful" or some such, indicating a preference for one solution over another, long before we actually declare the other solution historical. When IPv6 was younger, it made sense to remain neutral - IPv4 exhaustion was something we knew was happening, but we had no idea when or what it would mean, and IPv6 was so narrowly deployed that requiring it seemed exceptional. Now that we're at the "event horizon", it seems odd to not acknowledge the obvious flaw with IPv4 - we're out of unique addresses - and recommend an alternative, IPv6.

My view is that this really isn't about RFC compliance checklists that you'd see in an RFP from a company looking for network kit or software. Yes, the side effect is that this draft might get added to the list, but I don't think it actually makes any difference on that front. Those same companies are perfectly capable of defining (and testing) exactly which parts of IPv6 they want to have supported in the gear they're looking to purchase. This is more about the devices and software that are not normally built to some centralized purchasing requirement list, and therefore have no one telling them they must support IPv6.

The two goals that I see in this draft is that 1) IETF formally updates their guidance (to anyone who cares about IETF's guidance) that IPv6 is necessary and that while it will still have plenty of perfectly acceptable applications, supporting IPv4-only is not sustainable. 2) it updates the documents that define "IP" (actually IPv4) to refer to the equivalent documents that define IPv6 so that those looking for baseline protocol specs will find IPv6 and consider implementing even if they previously didn't even know that they needed it. There are implementations that happen in a relative vacuum using IETF standards as a guideline without necessarily being involved in the IETF process or interacting with people who might say something about IPv6. This might help to catch some of those.

Hopefully this helps to explain the goal in more pragmatic terms.

Wes George

---

From: Joel Jaeggli <[email-masked]>
Date: Sat, 4 Jun 2011 10:36:39 -0700

I think it's a little sad that we have to state the painfully obvious but I support the sentiment unequivocally.

joel

---

From: Bob Hinden <[email-masked]>
Date: Sun, 5 Jun 2011 18:13:27 -0700

> I think it's a little sad that we have to state the painfully obvious but I support the sentiment unequivocally.

+6

Bob

---

From: Warren Kumari <[email-masked]>
Date: Sun, 5 Jun 2011 22:30:03 -0400

> I think it's a little sad that we have to state the painfully obvious but I support the sentiment unequivocally.

This is the IETF -- stating the painfully obvious is what we do best...

W

---

From: Joe Touch <[email-masked]>
Date: Tue, 14 Jun 2011 18:37:18 -0700

+1

---

From: Julien Laganier <[email-masked]>
Date: Wed, 15 Jun 2011 09:31:38 -0700

Folks,

At this point the chairs believe that there is rough consensus in the
intarea WG to adopt this draft as a WG draft.

Authors: Please resubmit the draft as draft-intarea-ipv6-required-00.

--julien & scott

---

From: Julien Laganier <[email-masked]>
Date: Wed, 22 Jun 2011 11:22:43 -0700

Joe,

Because we' re talking about updating a venerable protocol I want to
make sure that we get the necessary level of review for this draft
before we forward it to IESG for publication as proposed standard.
I've asked a number of people to have a look at it, and below is the
first review from Erik (Thanks!)

--julien

---------- Forwarded message ----------
From: Erik Nordmark <[email-masked]>
Date: Wed, Jun 22, 2011 at 8:49 AM
Subject: Re: IPv4 ID update draft
To: Julien Laganier <[email-masked]>

On 6/22/11 8:17 AM, Julien Laganier wrote:
>
> Hi Erik,
>
> Have you read this draft of Joe:
>
> http://tools.ietf.org/html/draft-ietf-intarea-ipv4-id-update-02
>
> If so, do you think it is ready for publication?

No, I haven't read it.
I've sat through numerous presentations around the draft in the intarea WG.

I did a quick read.

I see text like
  This document attempts to address the security considerations
  associated with fragmentation in IPv4 [RFC4459].
which is confusing given that RFC 4459 talks about e.g.,
  router-based
  fragment reassembly could easily lead to (reassembly) buffer memory
  exhaustion

Clearly the id-update shouldn't claim to solve reassembly buffer
memory exhaustion, hence I think the above text around the reference
to RFC 4459 should be reworded.

On network rewrites:

Section 6.2 says
  For atomic datagrams, because the IPv4 ID field is ignored on
  receipt, it can be possible to rewrite the field. Rewriting can be
  useful to prevent use of the field as a covert channel, or to enable
  more efficient header compression. However, the IPv4 ID field needs
  to remain immutable when it is validated by higher layer protocols,
  such as IPsec. As a result:

  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.

  Protected datagrams are defined as those whose header fields are
  covered by integrity validation, such as IPsec AH [RFC4302].

Section 10 says:
  This document thus does not recommend whether atomic IPv4
  datagrams should use nonchanging or changing IDs, but rather allows
  those IDs to be modified in transit (as per Sec. 6.2), which can be
  used to accommodate more efficient compression as desired.

And section 11 says:
  When the IPv4 ID is ignored on receipt (e.g., for atomic datagrams),
  its value becomes unconstrained; that field then can more easily be
  used as a covert channel. For some atomic datagrams - notably those
  not protected by IPsec Authentication Header (AH) [RFC4302] - it is
  now possible, and may be desirable, to rewrite the IPv4 ID field to
  avoid its use as such a channel.

I don't see any significant benefits in allowing in-transit
modifications of the IP-ID (I'm not talking about the NAT case, which
in essence re-originates a datagram with different addresses/ports),
and I think we should be careful when tweaking this 20+ year old
protocol. Thus I don't think we should allow for in-transit
modifications of unprotected datagrams.

  Erik

---

From: Joe Touch <[email-masked]>
Date: Wed, 22 Jun 2011 13:30:13 -0700

Hi, all,

To discuss some points below...

On 6/22/2011 11:22 AM, Julien Laganier wrote:
> From: Erik Nordmark<[email-masked]>
> To: Julien Laganier<[email-masked]>
>
>

Will do. I have to look back to find the origin of that particular 
component...

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

There's actually a very specific reason for allowing in-transit 
modification - to avoid the assumption that this field can now be used 
in atomic packets for other E2E messaging -- as others have recently 
proposed, e.g., in draft-briscoe-intarea-ipv4-id-reuse

The goal is to make the ID field something the receiver must ignore, 
solely to avoid the (often ignored) requirement that the ID be unique 
within src/dst/prot tuple within 2MSL.

IMO, we can't "require" the field to be immutable E2E unless it's 
protected (e.g., by IPsec or encapsulation and a checksum of some kind). 
That's the point of "allowing" it to change - which also means it can 
change out from under anyone who uses it anywhere in the net, which 
prevents it being used for new mechanisms.

Given that context, do you think it's still important and/or feasible to 
prohibit in-transit mods?

Joe

---

From: Julien Laganier <[email-masked]>
Date: Wed, 22 Jun 2011 16:40:26 -0700

Hi Joe,

> Will do. I have to look back to find the origin of that particular

Ok.

> There's actually a very specific reason for allowing in-transit modification
> - to avoid the assumption that this field can now be used in atomic packets
> for other E2E messaging -- as others have recently proposed, e.g., in
> draft-briscoe-intarea-ipv4-id-reuse

I don't think that goal was in-scope for this I-D.

Also, since NAT may rewrite the I-D, it seems that the I-D can't be
used for that reliably, so maybe the I-D can mention that NATs may
rewrites IDs - rather than give blanket permission to intermediaries
to rewrite the IDs in unprotected atomic packets.

> The goal is to make the ID field something the receiver must ignore, solely
> to avoid the (often ignored) requirement that the ID be unique within
> src/dst/prot tuple within 2MSL.

IMHO the proper way to make the receier ignore the ID is to say MUST
ignore, rather than allowing intermediaries to rewrite it....

> IMO, we can't "require" the field to be immutable E2E unless it's protected
> (e.g., by IPsec or encapsulation and a checksum of some kind). That's the
> point of "allowing" it to change - which also means it can change out from
> under anyone who uses it anywhere in the net, which prevents it being used
> for new mechanisms.

Not requiring the field to be immutable doesn' t mean we have to allow
it to change...

> prohibit in-transit mods?

It' s not really about prohibiting in-transit mods, since NATs might
do that already. It is about not allowing it per this specification.
You can stil mention that NATs do rewrite it...

--julien

---

From: Joe Touch <[email-masked]>
Date: Wed, 22 Jun 2011 17:08:52 -0700

On 6/22/2011 4:40 PM, Julien Laganier wrote:
> Hi Joe,
>
> On Wed, Jun 22, 2011 at 1:30 PM, Joe Touch<[email-masked]>  wrote:
>> Hi, all,
>>

This point is mostly unchanged from its original discussion in the 
pre-WG version of the I-D, FWIW.

> to rewrite the IDs in unprotected atomic packets.

If we don't give blanket permission to change the ID in unprotected 
atomic packets, isn't that requiring them to be immutable?

I.e., we agree that we need to NOT assume that IDs of atomic packets are 
immutable; isn't that the same as allowing them to be modified in 
transit? Is there any other way to say "not immutable" than:
	
	- an intermediate node MAY rewrite the ID of an atomic packet

NATs rewrite src or dst addresses, but also (technically) need to 
rewrite IDs to be correct w.r.t. current RFC 791 rules - but they don't. 
I'm not clear that whether a NAT can/does rewrite an ID is useful 
towards this point.

> Not requiring the field to be immutable doesn' t mean we have to allow

See above (I.e., I can't see how it doesn't); if you can find a way to 
express that as a requirement, I'm game.

> You can stil mention that NATs do rewrite it...

Well that would kill the entire discussion on header compression. That's 
fine if we want to omit that. but if we do say that "ID is not immutable 
in atomic packets", that opens the door to a very useful optimization 
for compression that ought to be included IMO.

Joe

---

From: Julien Laganier <[email-masked]>
Date: Wed, 22 Jun 2011 18:34:25 -0700

Joe,

Cutting thru a bit:

On Wed, Jun 22, 2011 at 5:08 PM, Joe Touch <[email-masked]> wrote:
>>> modification
> This point is mostly unchanged from its original discussion in the pre-WG
> version of the I-D, FWIW.
>
> If we don't give blanket permission to change the ID in unprotected atomic
> packets, isn't that requiring them to be immutable?
>
> immutable; isn't that the same as allowing them to be modified in transit?
> Is there any other way to say "not immutable" than:
>

It seems to me that NOT assuming that IDs of atomic packets are
immutable is adequately captured by

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

no?

> NATs rewrite src or dst addresses, but also (technically) need to rewrite
> IDs to be correct w.r.t. current RFC 791 rules - but they don't. I'm not
> clear that whether a NAT can/does rewrite an ID is useful towards this
> point.
>
>>> solely
>>> protected

We don' t require the field to be immutable by making the mutability
properties of the field transparent to the receiver that ignores this
field in atomic packets...

> fine if we want to omit that. but if we do say that "ID is not immutable in
> atomic packets", that opens the door to a very useful optimization for
> compression that ought to be included IMO.

I do not think that this draft should update a 20 years old protocol
specification with the goal of opening doors to optimization of header
compression for that same protocol. I _think_ it was also the sense of
Erik's message.

--julien

---

From: Joe Touch <[email-masked]>
Date: Thu, 23 Jun 2011 11:17:52 -0700

Hi, Julien,

> Cutting thru a bit:
...
>     o>>  All devices that examine IPv4 headers MUST ignore the IPv4 ID

Let's say someone comes up with a crypto mechanism that isn't IPsec and 
isn't encapsulation, but a new IP option (IPsec++, for lack of a better 
description). Let's say that this new IPsec++ creates a hash that 
includes the ID field.

We'd need to assume that such a mod would violate the above requirement 
- since it is clearly not "ignoring" that field.

Then again, Bob Briscoe's doc would also violate the above requirement 
as well, since it clearly is examining the field.

If that's sufficient, we can use just that. However, I'd note that the 
*current* use of the ID field does not require that it be immutable.

E.g., the field is currently required unique within a src/dst/proto/ID 
tuple within 2MSL. There are two ways to accomplish that:

	- enforce uniqueness at the source and assume immutability
	in-transit

	- allow mutability in-transit so long as all such changes are
	coordinated to ensure that once the packets (fragmented or not)
	arrive at the receiver they follow the uniqueness rule

So, technically, if they're ignored, they're mutable, IMO - even if we 
don't say so.

My concern is that mutability is something people *will* disagree on, 
and that this doc needs to clarify that issue. The obvious clarification is:
	- if ATOMIC and not protected, then mutable (and ignored)
	- if not ATOMIC or protected (or both), then non-mutable

...
> field in atomic packets...

I agree, but I'm much more comfortable stating this explicitly if that's 
where the requirements end up pointing. I've found that derived 
requirements are not always derived consistently ;-)

I.e., if this is a consequence anyway, is there a good reason not to 
state it? (see below about compression, though)

> compression for that same protocol. I _think_ it was also the sense of

I agree with that - the sole point of this is NOT to enable header 
compression. It's just the indirect result of "receiver MUST ignore" for 
atomic unprotected packets as above.

However, the impact of these changes on the current header compression 
algs is useful to discuss, and if it enables an existing mode of 
compression we should note that (perhaps not encourage changing the ID 
solely for that purpose, though - let someone else propose that).

Would that work?

Joe

---

From: Julien Laganier <[email-masked]>
Date: Thu, 23 Jun 2011 13:08:05 -0700

Hi Joe,

On Thu, Jun 23, 2011 at 11:17 AM, Joe Touch <[email-masked]> wrote:
>>> transit?
> description). Let's say that this new IPsec++ creates a hash that includes
> the ID field.
>
> We'd need to assume that such a mod would violate the above requirement -
> since it is clearly not "ignoring" that field.

I am a bit confused... Are you arguing against the above requirement?
It isn't from me and is already in the draft...

> Then again, Bob Briscoe's doc would also violate the above requirement as
> well, since it clearly is examining the field.

Yes, and to the extent that we have consensus to update 791with the
above requirements it would be Bob's doc's issue...

> *current* use of the ID field does not require that it be immutable.

... neither does the above requirement.

> E.g., the field is currently required unique within a src/dst/proto/ID tuple
> within 2MSL. There are two ways to accomplish that:
>

The latter being unenforceable given that in-transit packets might not
all get along the same path, thus you're left with the former, no?

> So, technically, if they're ignored, they're mutable, IMO - even if we don't
> say so.

Technically, if they're ignored, they're ignored. It would follow that
there would be no problem caused by a receiving entity assuming the ID
is unique, neither if there existed an intermediary node that modified
the ID in transit. That however is different from our specification
authorizing intermediate node to modify the ID in transit...

> My concern is that mutability is something people *will* disagree on, and
> that this doc needs to clarify that issue. The obvious clarification is:

And by taking no stance on the mutability of IDs in atomic packets
people would not have to agree or disagree, intermediary nodes
wouldn't feel it's OK to change the ID, yet the requirement that the
field be ignored on the receiving end would prevent implementations to
rely on the supposed uniqueness of the ID, which I thought was out
intent...

> where the requirements end up pointing. I've found that derived requirements
> are not always derived consistently ;-)

Good that you agree.

It also appears that some people (including, but not limited to Erik,
myself, and Jari, if I am not mistaken) are much more comfortable not
changing IPv4 properties unless we have to, e.g., there's potential
harm.

> I.e., if this is a consequence anyway, is there a good reason not to state
> it? (see below about compression, though)

See above. There might be things that breaks when the ID of atomic
packets is changed by intermediary  nodes. Thus we don't want to
authorize change of ID in atomic packets.

>>> in

No.

Receiver ignoring the ID in atomic packets doen't result in the ID
being mutable.

Receiver ignoring the ID in atomic packets results in the consequences
of the ID being mutable being benign -- in nodes that implement the
recommendation.

Thus it's not a valid reason to allow the ID to be mutable -- because
there might still be nodes that do not ignore the ID in atomic
packets...

> However, the impact of these changes on the current header compression algs
> is useful to discuss, and if it enables an existing mode of compression we
> should note that (perhaps not encourage changing the ID solely for that
> purpose, though - let someone else propose that).
>
> Would that work?

Let's keep the header compression out of this discussion, I am finding
this issue is complex enough as is...

--julien

---

From: Joe Touch <[email-masked]>
Date: Thu, 23 Jun 2011 13:28:46 -0700

Hi, Julien,

On 6/23/2011 1:08 PM, Julien Laganier wrote:
> Hi Joe,
>
> On Thu, Jun 23, 2011 at 11:17 AM, Joe Touch<[email-masked]>  wrote:
>> Hi, Julien,
>>

I'm arguing that the above requirement may not be explicit enough, i.e., 
that someone reading *just* the above would conclude that IPsec++ would 
fail if it used the ID field.

> all get along the same path, thus you're left with the former, no?

The latter is enforceable within a terminus routing domain. It might not 
be practical, agreed.

> packets is changed by intermediary  nodes.

What could possibly break if it must be ignored by everyone who looks at it?

My concern is that I don't think there is such a thing - or ever can be, 
if the original "must be ignored" actually holds.

> Thus we don't want to

My conclusion is that if there clearly can't be anything that cares, 
then there can't be an impact to adding the "MAY change" rule.

If not having the "MAY change" rule bothers you because something would 
break, then we indeed have a problem - we have an instance of something 
that is supposed to ignore the ID that clearly isn't.

> there might still be nodes that do not ignore the ID in atomic

They would be in violation of the first requirement "that they ignore 
the ID".

So if you're going for backward compatibility, you want "SHOULD NOT 
modify the ID", but then you enable things that continue to look at the ID.

So, correct me if I'm wrong:

	- you're OK with everyone "MUST ignore the ID" of unprotected
	atomic packets

	- you don't want any other requirements that are derivative that
	would affect anyone violating this requirement (e.g.,
	"transits MAY modify")

I'd really like to hear from others in the WG on this point; it doesn't 
make sense to me to have a requirement and deliberately allow it to be 
ignored.

> this issue is complex enough as is...

Sure...

Joe

---

From: Julien Laganier <[email-masked]>
Date: Thu, 23 Jun 2011 14:11:11 -0700

Hi Joe,

On Thu, Jun 23, 2011 at 1:28 PM, Joe Touch <[email-masked]> wrote:
>>> includes
> that someone reading *just* the above would conclude that IPsec++ would fail
> if it used the ID field.

It might well be the case, I am not familiar enough with the IPsec++
specification and deployments to offer a definitive conclusion...

As to the requirement not being enough, I'd argue that we don't want
to let the perfect be the enemy of the good. The status quo here is to
do nothing. If we have a requirement that says ignore on the receiving
end, we're removing some issues, aren't we? On the other hand, there
are been concerns in this draft going too far in modifying a 20 years
old deployed and running protocols, including allowing in-flight
modification of the ID. These concerns would be addressed by
eliminating the allowance (MAY) given to do so...

So that is better than the status quo which is the default mode of operation...

>>> tuple
> The latter is enforceable within a terminus routing domain. It might not be
> practical, agreed.

Right.

>>> don't
>>> state

t would be ignored by receiver that follows that update to RFC 791,
not necessarily by all nodes in the installed legacy base. Thus if it
were modified in transit by a node that felt compelled to so by this
update to RFC 791, but the packet was ultimately received by a node
who didn't know it had to ignore that we could have problems.

> My concern is that I don't think there is such a thing - or ever can be, if
> the original "must be ignored" actually holds.

See above.

> My conclusion is that if there clearly can't be anything that cares, then
> there can't be an impact to adding the "MAY change" rule.

There can't be an impact on receiver that follows this update. That
ain't true for receivers that do not.

> break, then we indeed have a problem - we have an instance of something that
> is supposed to ignore the ID that clearly isn't.

See above.

It's also not only me that is bothered, Erik originally expressed the
concern and I agreed.

> They would be in violation of the first requirement "that they ignore the
> ID".
>
> So if you're going for backward compatibility, you want "SHOULD NOT modify
> the ID", but then you enable things that continue to look at the ID.

I do not want to change the behavior of IPv4 w.r.t. to the ID unless I
am solving an issue. What issue are you solving by having a MAY
modify?

>        would affect anyone violating this requirement (e.g.,

As discussed earlier I disagree they are derivative.

Is your intent with MAY modify to negatively affect implemetation that
do not observe the first requirement MUST ignore the ID? That doesn't
seem desirable, at all.

> I'd really like to hear from others in the WG on this point; it doesn't make
> sense to me to have a requirement and deliberately allow it to be ignored.

For now what you have from this WG is feedback that allowing the ID to
be changed isn't desirable.

>>> algs

--julien

---

From: Joe Touch <[email-masked]>
Date: Thu, 23 Jun 2011 15:08:26 -0700

Hi, Julien (et al.),

Cutting this down a bit (actually a lot),

On 6/23/2011 2:11 PM, Julien Laganier wrote:
...
> specification and deployments to offer a definitive conclusion...

To clarify for the benefit of others on the list as well, there is no 
IPsec++ - I created it as an example for the discussion only...

> do nothing.

Fair enough. I will update the draft accordingly, and remove or at least 
discuss differently the header compression issue.

Joe

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 27 Jun 2011 21:00:15 -0700 (PDT)

>>>>> On Wed, 22 Jun 2011, Julien Laganier wrote:
Julien> Because we' re talking about updating a venerable protocol I 
Julien> want to make sure that we get the necessary level of review 
Julien> for this draft before we forward it to IESG for publication 
Julien> as proposed standard. I've asked a number of people to have 
Julien> a look at it, and below is the first review from Erik 
Julien> (Thanks!)

Here is an unsolicited review of the draft in question 
(draft-ietf-intarea-ipv4-id-update-02) from an outsider.

I agree with the specification changes made in Section 6.1, which 
disallow the use of the IPv4 ID field for purposes other than 
fragmentation and reassembly.  I agree that these changes will have 
little, if any, impact on fielded implementations, and may indeed 
help to mitigate actual operational problems documented in RFC 4963, 
"IPv4 Reassembly Errors at High Data Rates."

However, I do NOT agree with Section 6.2, and I believe that the 
changes proposed in that section should be dropped, or at the very 
least, better justification needs to be provided for making these 
non-backward compatible to a nearly 30 year old protocol.  In 
particular:

- The proposed ban on overlapping IPv4 fragments is ill-motivated.  
  Section 6.2 cites RFC 4963 to support the assertion that 
  overlapping fragments are a security hazard, but I was not able to 
  find any discussion of overlapping fragments in that RFC.  This 
  subject _is_ discussed in RFC 1858 and RFC 3128, but the hazards 
  discussed those RFCs result in middlebox packet filtering failures 
  and can be addressed by localized changes to the middleboxes, 
  without making a global change to IPv4.  If there is any 
  literature that documents a security hazard from overlapping 
  fragments in a properly implemented system that defers header 
  processing until a complete IP datagram is fully reassembled, I 
  have not been able to find it.  Indeed, it should be noted that 
  overlapping fragments are in principle legitimately possible if a 
  non-atomic datagram is duplicated within the network and the 
  duplicates are then fragmented in different ways.

- The proposed ban on reusing the same ID when retransmitting an 
  identical datagram is ill-motivated because in this case 
  repetition does not lead to the type of reassembly errors 
  documented in RFC 4963.  The errors discussed in RFC 4963 arise 
  when different non-atomic datagrams have the same ID.

- The proposed change to allow the ID field of non-atomic datagrams 
  to be changed in transit is ill-motivated.  Erik Nordmark's review 
  (and the dubsequent discussion) has already dealt with this point 
  at length.

Recently (albeit another context) Brian E Carpenter wrote:
Brian> We shouldn't be spending any effort on polishing the IPv4 
Brian> heirloom, except for vital security or operational fixes.

I agree with the changes proposed in Section 6.1 because they 
provide fixes for a documented operational issue.  I disagree with 
the changes in Section 6.2 because they amount to unnecessary (and 
probably even harmful) polishing of the IPv4 heirloom.

Thanks and regards,

Mike Heard

P.S. One nit: the next-to-last paragraph of Section 4 states: "The 
IPv4 ID field can also be used to validate payloads of ICMP 
responses as matching the originally transmitted datagram at a host 
[RFC4963]."  I was not able to find any such discussion in RFC 4963, 
and I think the reference should either be corrected or dropped.