Subject: Need your input on draft-ietf-6man-exthdr

From: Suresh Krishnan <[email-masked]>
Date: Mon, 3 Jan 2011 08:20:00 -0500

Hi Folks,
    As some recent mails indicated there does not seem to be consensus on
some parts of this draft. I would like to see what the wg feels (now)
before proceeding any further with this draft.

The draft contains three independent components

a) Specifying a uniform format for all future IPv6 extension headers to
make them easier to parse/process.
b) Requesting a single IP protocol number codepoint for all future
extension headers and multiplexing them using a Specific Type field
inside the generic header.
c) Specifying error-handling and drop behavior for dealing with unknown
extension headers.

  From what I have seen there seems to be no opposition to a) but there
is  for b) and c). I will try to (loosely) summarize the viewpoints on
b) and c) and see if we can agree on what to do about them.

b) was added due to wg feedback
===============================

Pros:
1) Allows middleboxes to differentiate between unknown extension headers
and unknown transport protocols
2) Reduces the strain on the protocol number space

Cons:
1) Uses up one protocol number even if no now extension headers are ever
defined
2) Any new extension header (including this one) will break existing
silicon.

c) was added due to the decision reached at the IETF79 wg meeting
=================================================================

Pros:
1) Allows flexible handling behavior for dealing with unknown headers

Cons:
1) Violates RFC2460
2) Duplicates the functionality provided by Destination options
3) Unnecessary

META-question
=============

RFC2460 allows the use of both extension headers and options to convey
optional information, I would like to add some text into this draft
suggesting that destination options are the preferred mechanism of doing
so (since they offer better backward compatibility). Something like

"RFC2460 allows the use of both extension headers and destination
options in order to encode optional destination information in an IPv6
packet. The use of destination options to encode this information,
provides more flexible handling characteristics and better backward
compatibility than using extension headers. Because of this,
implementations SHOULD use destination options as the preferred
mechanism for encoding optional destination information, and use a new
extension header only if destination options do not satisfy their needs.
The request for allocation of a Specific Type value MUST be accompanied
by an specific explanation of why destination options could not be used
to convey this information."

Would this be an acceptable thing to add here?

I would appreciate the WG's opinion on these issues/questions before
going forward with this draft.

Thanks
Suresh

---

From: Rémi Després <[email-masked]>
Date: Tue, 4 Jan 2011 10:34:52 +0100

> From what I have seen there seems to be no opposition to a)

No opposition AND positive support:

Skipping unknown extension headers can be useful not only in FWs but also in some other places (e.g. in some variants of load balancers) 

As Fernando noted, FWs that do "default deny" shouldn't be concerned.
However, not all FWs are necessarily default deny in the strict sense (i.e. with all fields of accepted packets having to be described)
It may be useful to say, for example, "accept all incoming connections to address X and port 80" without concern for extension headers.

Besides, someone, Mark Townsley I believe, described a FW behavior where:
- packets known to be good are accepted
- packets known to be bad are discarded
- unknown packets are rate limited
This is IMHO an interesting possibility that differs from just "default deny".

Points b and c are more debatable.
I don't find them necessary.
The draft would IMHO be better without them,  but I don't object.

The proposed addition in the "Meta question" seems useful => +1
(But the document remains acceptable without it.)

Regards
RD

> but there
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Tony Li <[email-masked]>
Date: Thu, 6 Jan 2011 08:52:27 -0800

> make them easier to parse/process.

Support

> inside the generic header.

Object: We have not demonstrated necessity.

> c) Specifying error-handling and drop behavior for dealing with unknown

This turns out to be a corollary of a), so I support this as well.  Once you say that things are a TLV, the behavior should be obvious to one skilled in the art.

Tony