Subject: Mutable fields and the Hop-by-Hop and Destination Options headers

From: Brian Zill <[email-masked]>
Date: Tue, 14 Nov 2000 21:10:22 -0800

Hi all, got a question about mutable options.

As described in RFC 2460, Option Type identifiers have an encoded bit (aka
the mutable option bit)  indicating "whether or not the Option Data of that
option can change en-route to the packet's final destination".  This allows
new IPv6 options to be defined with contents that may be changed by either
routers or intermediate destinations along the way to the final destination,
without breaking IPsec authentication.

RFC 2460 also specifies the recommended Extension Header Order as:

IPv6|HbH|DO1|RH|FH|AH|ESP|DO2|TCP/UDP/etc

where DO1 is "for options to be processed by the first destination that
appears in the IPv6 Destination Address field plus subsequent destinations
listed in the Routing header", and DO2 is "for options to be processed only
by the final destination of the packet".  The exact order is only a
recommendation, but the distinction between Destination Options headers that
appear before the Routing Header versus those that appear after it is the
important part here.

From the above, one could reasonably conclude that mutable options should
only appear in Hop-by-Hop and Destination Options 1, and not in Destination
Options 2.  Options that appear in DO2 have no need to be mutable since this
header is never examined until after the packet has arrived at the final
destination.  And in fact, if they were mutable and mutated in-flight, they
would break things like ESP in null-encryption authentication-only mode.

Unfortunately, this requirement that mutable options not appear after the
Routing Header is not explicitly stated in the spec anywhere.  And it
matters for how one calculates the ICV when processing AH headers (since the
calculation treats mutable options as zeroed fields in all cases).  If one
allows mutable options to appear anywhere, then the AH ICV calculation needs
to parse past the AH header through to the end of the packet, instead of
being able to treat everything inside of the AH header as an opaque blob.
This would needlessly complicate the AH ICV calculation for no practical
reason.

Therefore, I'd like to propose that the spec is clarified to limit mutable
options to where they make sense, i.e. in Hop-by-Hop and Destination Options
headers that appear before the Routing Header.

Comments?

Thanks,
--Brian

P.S.  As an aside, it occurs to me that it might be clearer to define a new
"Intermediate Destination Options" header to take the place of DO1.  Then it
could be declared that this new header (if present) MUST appear before the
Routing Header, and that mutable options (if present) MUST appear in either
this new header or a Hop-by-Hop header.  Or to put it another way, mutable
options wouldn't be allowed any more in a Destination Options header.  This
would also make the spec cleaner - it could get rid of the special case
notations explaining the difference between DO1 and DO2.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Wed, 15 Nov 2000 10:21:06 +0100

In your previous mail you wrote:

=> yes but this bit is not used today (this is not a proposal to remove it,
I believe it is a very useful feature).

   
=> this recommendation has three problems:
 - DO1 makes sense only when there is a routing header. This is not clear
   enough!
 - an IPComp (RFC 2393) header should be between ESP and DO2
 - there are two kinds of DO (DO1 and DO2) which makes implementations hairy
   and the recommendation unclear (see first point). As the third placement
   (between RH and FH) for DO header seems to be very useful for home address
   (cf mobile IP discussion) and tunnel encapsulation limit (DO2 makes it
   near useless) options the whole DO placement stuff should be redone.
   I've proposed a solution but I *never* get an answer (even negative :-).

   Options that appear in DO2 have no need to be mutable since this
   header is never examined until after the packet has arrived at the final
   destination.  And in fact, if they were mutable and mutated in-flight, they
   would break things like ESP in null-encryption authentication-only mode.
   
=> I agree that mutable options in DO2 should be forbidden (just because
they don't make sense).

   Unfortunately, this requirement that mutable options not appear after the
   Routing Header is not explicitly stated in the spec anywhere.

=> I don't believe we need to state this now. It should be done only
if/when someone proposes a mutable option which is not hop-by-hop
(I don't think DO1 is still useful but there were some (rejected) proposals
for mutable hop-by-hop options).

   And it
   
=> this is a different point because "after AH" is not the same thing than
"before RH". You can apply your ESP argument too here...
Perhaps you should support my DO header cleanup, I'll add a mutable-forbidden
statement for DO2 (:-)...

=> if nobody has an usage for DO1 I think we should phase it out and
simplify your proposal in mutable implies hop-by-hop.
   
   P.S.  As an aside, it occurs to me that it might be clearer to define a new
   "Intermediate Destination Options" header to take the place of DO1.

=> I agree, in DO1 and DO2 are too many choices. I believe for the new
header you want a new type?

   Then it

=> we agree at least on the necessary cleanup for DO headers.

Regards

[email-masked]

---

From: Robert Elz <[email-masked]>
Date: Wed, 15 Nov 2000 19:30:44 +0700

Date:        Tue, 14 Nov 2000 21:10:22 -0800
    From:        Brian Zill <[email-masked]>
    Message-ID:  <[email-masked]>

It certainly makes no sense to have to allow specially for
the possibility of mutable options, which cannot in fact mutate.

I kind of like Steve's suggestion ...

  > Alternatively, we could specify that any mutable options that appear
  > after the AH header are treated as if they were immutable

except we can generalise that - anything that is internal to any header
(part of the payload of that header) must be able to be treated as immutable
for the purposes of the header.

There can never be (rationally) a need to peel back the onion and look inside
the payload to attempt to interpret any particular header.

The mutable/immutable stuff is needed only because we need to have the
security headers apply to data that is strictly outside their scope
(data from headers in which they're wrapped), and for that, allowance
that things might sometimes change is unavoidable.  Some of that is
just handled by rules "the hop count field varies", but where data yet
to be invented exists (options) the method to make clear which is
mutable, and which is not is clear - but only in headers that come outside
the header which cares.

But...

  | P.S.  As an aside, it occurs to me that it might be clearer to define a new
  | "Intermediate Destination Options" header to take the place of DO1.

Please, no - the double use of the DO header is a thing of beauty.
It, just by being there, makes clear the way the IPv6 header structure
is to work, it makes clear that headers can appear more than once,
it makes clear that the interpretation of a header depends upon where
in the sequence of headers it is found, it makes clear the onion
peeling parsing technique that is defined to apply to IPv6 headers,
and is a very clean architectural design.

Please don't mess with this just because it seems easier to fix everything
in concrete (this follows this follows this...) and pretend that variations
are never going to be possible.  (Aside from that it would be a waste
of one of the 256 header type codes for no reason whatever).

kre

---

From: Francis Dupont <[email-masked]>
Date: Wed, 15 Nov 2000 14:35:51 +0100

But...

=> the beauty of the Hell if you try to implement it...

=> can you explain how you express this (for instance the
   interpretation of a header depends upon where it is found)
   in an API?

   Please don't mess with this just because it seems easier to fix everything
   in concrete (this follows this follows this...) and pretend that variations
   are never going to be possible.

=> variations should be possible in reception but should not be possible
in emission. I can't see a good reason to keep the complexity (with bugs
in implementations and done by programmers) because we have no real use
of it. The current recommendation level (SHOULD) is the good one (I agree
a MUST would be too strong).

   (Aside from that it would be a waste of one of the 256 header type
    codes for no reason whatever).
   
=> near half of the space (120 codes) is still free. My concern is
more the delay for a new code than the waste...

Regards

---

From: Vladislav Yasevich <[email-masked]>
Date: Wed, 15 Nov 2000 10:31:03 -0500

> notations explaining the difference between DO1 and DO2.

Brian

I agree with you that Destionation Options headers need to be clarified.  In
fact, Ken Powel and I talked about this a few days agoa and came up with almost
the same solution you have described above.  The only difference was that we did
not require the Routing Header.  In our conversation, this "Intermediate
Destination
Options" (I kind of like this name) would go after Hop-by-Hop (if present) or
after the IPv6 header (if HbH is not present).  This header would be
non-fragmentable.

This header would provide the location for any options that may be mutable
and/or
any options that may have to be examined by some of the hops along the way to
the destination, eg. Tunnel Limit Option, Home Address Option, etc.

-vlad 
++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Tel: (603) 884-1079
Compaq Computer Corp.		Fax: (435) 514-6884
110 Spit Brook Rd ZK03-3/T07
Nashua, NH 03062
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Dirk Ooms <[email-masked]>
Date: Fri, 17 Nov 2000 14:58:10 +0100

I have the impression that a lot of the complexity in these chained
extension headers is caused by the way Source Routing is specified.

If Source Routing would be a hop-by-hop extension and the IPv6
destination was always the final destination the header mess wouldn't be
that big (the disadvantage being that Loose Source Routed packets need
additional procesing in non-fixed hops, but who is using Source Routing
anyhow?).

dirk

---

From: Steve Deering <[email-masked]>
Date: Fri, 17 Nov 2000 07:49:43 -0800

>extension headers is caused by the way Source Routing is specified.

The chained headers aren't complex.  (Warning: digression ahead...)
The issues under discussion arise from the extra-architectural use of
layer-violating devices along a delivery path.  The Flow Label is in
IPv6 specifically to avoid the need for (and the parsing expense/
complexity of ) looking at transport-layer port fields to do flow
classification.  Perhaps we ought to have moved the port fields into
the IP header instead, as in Xerox's XNS / Novell's IPX; that was
actually considered and discussed at great length in the early days
of IPv6's predecessor, SIP, and rejected as being too radical a change
to the IP architecture which would have required significant redesign
of IP implementations.  And though that would have made it easier to
do port-based firewall filtering for IPv6, it wouldn't have helped all
the other forwarding-path layer-violations that some people deem
desirable today, e.g., stateful firewalls, "performance-enhancing
proxies", "layer 7 switching", etc., but all of those are at odds with
end-to-end encryption, which we were/are hoping will someday become
common in the Internet.  Better to put the effort into IP-architecture
-compatible solutions to those other problems.

I'm also surprised that people are using the rationale that speeds are
increasing to argue for changing IPv6 to make it easier for the routers
to do more functions than just forwarding packets. I would think that
ever increasing speeds are a reason to *reduce* the number of tasks that
routers do.  (For example, that's why we eliminated a header checksum
from IPv6.)

>additional procesing in non-fixed hops, but who is using Source Routing

Mobile IPv6 is using the Routing header.  There's some chance that that
that header will show up in a significant number of IPv6 packets, some day.
(I happen to think it was a mistake to use the Routing header for Mobile
IPv6 -- encapsulation would have been much better -- but it's probably
too late to do anything about that now.)

Steve

---

From: Francis Dupont <[email-masked]>
Date: Fri, 17 Nov 2000 18:06:14 +0100

that big

=> hop-by-hop means to be processed by each router on the path...
What you propose in fact is to kill the routing header facility
(as it was for IPv4 in the real world) but I am sorry but the routing
header is useful, for instance for mobility (routing optimization needs it)
and policy routing.

   (the disadvantage being that Loose Source Routed packets need
   additional procesing in non-fixed hops,

=> IPv6 routing header type 0 (other types are not used) is *loose* source
routing.

   but who is using Source Routing anyhow?).

=> see before.

---

From: Steve Deering <[email-masked]>
Date: Fri, 17 Nov 2000 07:54:47 -0800

>and is a very clean architectural design.

Yes, that's what I should have said.

:-)

Steve

---

From: Robert Elz <[email-masked]>
Date: Mon, 20 Nov 2000 18:49:47 +0700

Date:        Wed, 15 Nov 2000 14:35:51 +0100
    From:        Francis Dupont <[email-masked]>
    Message-ID:  <[email-masked]>

  | => can you explain how you express this (for instance the
  |    interpretation of a header depends upon where it is found)
  |    in an API?

Not the way you're expecting no.   But that's because the current APIs
are more like assembler level programming - the application says exactly
what it wants, but other than building the packet in user space and simply
telling the kernel to send it, the API doesn't have the generality to
express much useful.   Basically the current API provides an interface
where the application builds the packet (conceptually) but has the
kernel (the thing under the API, which could also be library routines)
do all the bookkeeping and grunge work.

A better API would allow the application to express its intent at a
higher level - rather than "add fragmentation header" it would say
something more like "I want to send unit packets N bytes long", and
then the kernel might determine that that required a fragmentation
header to be added (or not, in a particular case).

With a less packet specific API, the application expresses its desire
and the kernel (stack) implements it - and if to do that means putting
options in the hop by hop header, then fine, or if it can be done by
sticking them in DO1, then fine, or if it can be done by sticking them
in DO2, also fine - of if sticking a DO header between ESP and AH is
what achieves the goal, that's just fine as well, or putting it between
the routing header and the frag header achieves it, fine too.  The latter
might be appropriate for an option that was intended to be parsed before
reassembly, but only at the final destination - perhaps one to control
how reassembly should proceed - maybe timer setting or something, and the
API would be "reassemble in 10ms or drop" from the application to the stack.

kre