Subject: draft-krishnan-ipv6-exthdr, notes from Beijing

From: RJ Atkinson <[email-masked]>
Date: Mon, 15 Nov 2010 14:02:18 -0500

I do NOT support this draft, for one quite simple reason:

** The assumption of this draft is that there exists some 
   IP option type that is NEITHER (a) hop-by-hop nor
   (b) end-to-end in nature.

I have never heard of such an option, but if someone
can provide a concrete example I'm eager to hear about it.

By contrast, I know of equipment deployed today (and for
the past few years) from more than 1 router/firewall vendor 
that already has silicon that can parse (and, significantly, 
parse PAST) IPv6 Destination Options or IPv6 Hop-by-Hop 
Options in order to discover the transport-layer protocol
and transport-layer protocol header values (e.g. port numbers).  

A common deployed use for this capability is to make access 
control decisions based in part upon the transport-layer protocol 
and transport-layer port numbers, even in the presence of IPv6
optional headers.

Standardising this proposal has the effect of breaking
this *deployed* capability, which is important to a 
significant installed base that use this capability today.

Now, I happen to be familiar with the internals of at least
one of the chips with this capability.  Adding that capability
did not significantly increase the gate count and did not
increase the die-size of a die already pretty full with 
other stuff.  So there are multiple existence proofs that
one can design and fabricate silicon with the deployed
approach.  Whether a particular implementation does this
or not is largely a business decision, rather than a technical
decision.

We do not want to encourage the creation of ANY IPv6 option
that is NEITHER a Destination Option NOR a Hop-by-Hop option
and consequently are NOT carried inside either of those headers.

Yours,

Ran Atkinson
[email-masked]

---

From: "Hing-Kam (Kam) Lam" <[email-masked]>
Date: Wed, 17 Nov 2010 05:23:47 +0530

> can provide a concrete example I'm eager to hear about it.

You got the intent all wrong. The intent of draft-ietf-6man-exthdr
(formerly known as  draft-krishnan-ipv6-exthdr) is to standardize the
IPv6 extension headers that might get proposed in the future so that
(i) parsing becomes deterministic and easy AND (ii) we dont end up
using any more protocol code points from the limited range that
exists. I believe the consensus is now to also include some fields in
GIEH that indicate what a processing node must do when it does not
recognize the new extension header type thats being carried in GIEH.

> and transport-layer protocol header values (e.g. port numbers).

..

> significant installed base that use this capability today.

Standardising any new protocol number will break this deployed box.
How will this box be able to parse a new extension header that is
introduced when it does not understand this.

> and consequently are NOT carried inside either of those headers.

The draft does not do that. I dont know which version you have been
reading. You should read draft-ietf-6man-exthdr and
draft-bhatia-6man-update-ipv6-ext-hdr to get an idea of the problem
that this draft is attempting to solve.

Kam

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Wed, 17 Nov 2010 01:45:27 +0100

>that this draft is attempting to solve.

Hing is absolute correct - this mechanism is necessary, there are no valuable
alternatives.

Or to quote the Linux Kernel:

int ipv6_ext_hdr(u8 nexthdr)
{
        /*
         * find out if nexthdr is an extension header or a protocol
         */
        return   (nexthdr == NEXTHDR_HOP)       ||
                 (nexthdr == NEXTHDR_ROUTING)   ||
                 (nexthdr == NEXTHDR_FRAGMENT)  ||
                 (nexthdr == NEXTHDR_AUTH)      ||
                 (nexthdr == NEXTHDR_NONE)      ||
                 (nexthdr == NEXTHDR_DEST);
}

If the extension header is no well known extension header (see the code) the
network stack must stop processing of the packet! The kernel will drop the
packet. Why? Because Transport Protocols on top of IPv6 does not underly a TLV
coding. If the Kernel does not know the extension header type (e.g.
NEXTHDR_FRAGMENT) what should he do? The kernel does not know if it is a
unknown extension header or a unknown transport protocol. And because a
transport protocol has no TLV coding he cannot skip over a transport protocol.
Think about it, it may take some time but the current mechanism was the only
workable way. The alternative would be to re-define all existing Transport
protocols (TCP2, UDP2), this time with a identical TLV encoding.

Another solution where to introduce a white list for transport protocol types
(TCP, UDP, ...) - but this time you would restrict the development of new
transport protocols. If the kernel does not know the protocol type he must skip
this packet. Same problem but this time even worse, because you limit the
transport protocol development.

The situation now is that the Kernel must know all Extension Header Types, a
unknown Extension header will stop the processing chain.

Hagen

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Wed, 17 Nov 2010 01:52:40 +0100

One final note: GIEH will provide a transparent extension header container.
The kernel must know the GIEH extension header, the inner extension header
can be everything. If the Stack know GIEH he can skip it - including the
(possible unknown) encapsulated header.

No new extension header types must be added to the quoted header validator
code in the network stack.

Hagen

---

From: Steven Blake <[email-masked]>
Date: Tue, 16 Nov 2010 20:58:39 -0500

On Wed, 17 Nov 2010 01:45:27 +0100, Hagen Paul Pfeifer <[email-masked]>
wrote:

> packet. Why? Because Transport Protocols on top of IPv6 does not underly
a
> TLV
> transport protocols. If the kernel does not know the protocol type he
must
> skip
> The situation now is that the Kernel must know all Extension Header
Types,
> a

This does not address Ran's comment: why would we ever need a new
extension header?  Why aren't the Hop-by-Hop Options and Destination
Options extension headers sufficient?  Neither of the drafts above motivate
this need.

Regards,

// Steve

---

From: "Hing-Kam (Kam) Lam" <[email-masked]>
Date: Wed, 17 Nov 2010 07:43:01 +0530

> Options extension headers sufficient?  Neither of the drafts above motivate

Read RFC 3775 - Why didnt they reuse the existing extension headers.
Similarly, there will be other proposals which may, for several
reasons, not want to reuse existing option headers. Fast parsing in
the HW could be one reason, why you may not want to reload too much
into an existing option header.

Kam

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Wed, 17 Nov 2010 09:52:37 +0100

> Options extension headers sufficient?  Neither of the drafts above
motivate

Tunnel specific extension header, efficient low overhead extension header,
... whatever.

The current extension header mechanism isn't practical, but why should we
wipe out these extension header at all? Introduce GIEH as a generic
container and everything is fine.

Hagen

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 17 Nov 2010 08:31:46 -0500

On 16  Nov 2010, at 19:45 , Hagen Paul Pfeifer wrote:
> Hing is absolute correct - this mechanism is necessary,
> there are no valuable alternatives.

As I've described in my response to him earlier today, 
the I-D doesn't actually solve the problem that you all 
describe, because some different IETF WG can create a new 
protocol (e.g., some non-IPv6-specific protocol), with 
a new Protocol number assignment, using any syntax that
WG desires to use.

The IETF IPv6 WG lacks authority over, for example, IETF WGs 
in the RAI, Applications, or TSV Areas that might define
generic extensions that use Protocol number values and
whose extensions apply both to IPv4 and IPv6.

A simpler alternative -- and one that actually DOES solve the
concern you all seem to have -- is to require all future IPv6
extensions to use either the Destination Options or Hop-by-Hop
headers, which already have quite clearly defined syntax rules,
are already supported by deployed systems, and are already parsable 
by deployed silicon.

> network stack must stop processing of the packet!

A complete fix for the issue you all express concern about is 
to clarify that all IPv6-specific extensions MUST NOT create 
a new extension header, and instead MUST use either the existing
Destination Options header or the Hop-by-Hop Options Header.

This restriction is consistent with and only slightly stronger
than the severe restrictions on new end-to-end extension header
creation that is already present in RFC-2460 Section 4.6 
(see also my other reply of this morning).

If someone can come up with a single example of a potential 
extension that is neither hop-by-hop nor end-to-end in nature, 
then the paragraph above might need to be edited slightly.

Your assumptions that I don't understand IPv6 or kernel code 
are both demonstrably false.  In fact, I've got a lot more 
experience with IPv6 options than most folks, see for example 
RFC-5570 and draft-rja-ilnp-nonce.  I was also part of the team 
that developed the VERY first IPv6 implementation in the entire world 
(i.e. NRL IPv6+IPsec for 4.4 BSD) -- we had working IPv6 packets on 
Ethernet BEFORE the IPng decision was announced.  So I've got 
specific IPv6 kernel experience going back to 1995.

Yours,

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 17 Nov 2010 08:36:13 -0500

> Standardising any new protocol number will break this deployed box.

No.  

Only adding new non-terminal protocols with distinct Protocol
numbers could break the deployed systems.  Having the IETF TSV 
Area define, for example, a new transport protocol does not break 
the deployed systems.

> introduced when it does not understand this.

Protocol numbers can be assigned by IANA in response to a request
from nearly any WG in any IETF Area, and usually are not even 
IPv6-specific.  

This draft would only apply to a new IPv6-specific Protocol 
number assignment, so it can not solve the problem you describe.

> reading. 

It does encourage development of such IPv6 optional headers -- 
simply by saying  this is how one specifies new IPv6 header types.

RFC-2460 says that new optional headers ought NOT be created
except under very carefully defined narrow circumstances
(RFC-2460 Section 4.6, but read my text below first :-).
This draft's language is not fully aligned with RFC-2460
at present.

At a bare minimum, this draft needs editing to be fully aligned
with RFC-2460, including new text to say explicitly that: 

	"Any new IPv6 extension MUST use either the existing 
	IPv6 Destination Options Header or the existing IPv6
	Hop-by-Hop Options Header if the new extension has 
        either end-to-end or hop-by-hop properties."

Note also that the paragraph I've written above is only slightly
stronger than what RFC-2460 already says about creating new 
optional headers (see Section 4.6, specifically the bottom 
of Page 23 and the top of Page 24 in RFC-2460).

Yours,

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 17 Nov 2010 08:44:40 -0500

> Tunnel specific extension header, efficient low overhead extension header,

Those are all destination oriented, and do NOT meet the narrow 
special-case criteria in RFC-2460 Section 4.6, so those are 
*already prohibited* as IPv6-specific extensions by Section 4.6 
of RFC-2460.

Separately, the IETF already has more tunnel headers than it needs,
so the IESG is extremely unlikely to approve something new, and
instead is likely to tell folks proposing another tunnel header
to reuse something that already exists. 

> The current extension header mechanism isn't practical,

RFC-5570 and draft-rja-ilnp-nonce are existence proofs 
that the current mechanisms ARE practical to use. 

(Really, I've got more experience with this than most folks. :-)

> but why should we wipe out these extension header at all?

Indeed, we ought not.  We ought to be using them as intended,
because we have existence proofs they work well.  :-)

> Introduce GIEH as a generic container and everything is fine.

Not correct.

Other IETF Areas and other IETF WGs might still define
extensions that don't follow draft-krishnan-ipv6-exthdr.
By its very language, that I-D is specific to IPv6, and 
doesn't apply across the entire IETF.

Yours,

Ran

---

From: Steven Blake <[email-masked]>
Date: Wed, 17 Nov 2010 09:59:21 -0500

> container and everything is fine.

Hop-by-Hop Option and Destination Option headers are both just simple
TLV containers for options. GIEH is just a simple TLV container for
extension headers.  Unless you forsee an option that must be processed
both at intermediate nodes and at the destination, I really don't see
the point.

Regards,

// Steve

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 17 Nov 2010 11:39:23 -0500

Hi Ran/Steve,
   If your objection is "We should not be defining any new extension 
headers", I completely agree with you. But, I guess the sentiment has 
not gone around the IETF. The following IPv6 extension headers have been 
defined since RFC2460

135 - Mobility header
139 - HIP
140 - Shim6
141 - WESP

Right now the fact remains that the IPv6 spec allows for using a 
separate header as an option.

" If the desired action is for the destination node to discard
   the packet and, only if the packet's Destination Address is not
   a multicast address, send an ICMP Unrecognized Type message to
   the packet's Source Address, then the information may be
   encoded either as a separate header or as an option in the
   Destination Options header whose Option Type has the value 11
   in its highest-order two bits.  The choice may depend on such
   factors as which takes fewer octets, or which yields better
   alignment or more efficient parsing."

I would be just as happy if such a statement was made and could gather 
consensus in the 6man wg.

Thanks
Suresh

On 10-11-17 09:59 AM, Steven Blake wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 17 Nov 2010 12:19:51 -0500

One of the confusions here is that the same field (next header) is used 
to identify extension headers and carried protocols.   I am sure that 
the authors are not demanding that we change the TCP, UDP, SCTP, DCCP, 
or ICMP header formats.  I presume that they are not asking that we 
constrain the header format of new transport protocols.

As such, tunnel protocols are probably not a good example of the need 
for extension headers.  They behave as encapsulating headers, hence they 
are really a carried protocol, not an extension of the IP header.

Also, I do not see why a new extension header would be noticeably more 
efficient than adding an option in the proper option header (with the 
option header having the advantage of being clear about who the 
information is for.)

On a related note, RFC 2460 actually mandates that new extension headers 
be created ONLY for headers which meet specific handling constraints. 
Putting handling directives in the extension header means that we are 
explicit reversing a statement in RFC 2460.

Yours,
Joel M. Halpern

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 17 Nov 2010 12:19:48 -0500

On 17  Nov 2010, at 11:39 , Suresh Krishnan wrote:
>  If your objection is "We should not be defining any new extension headers",

(That is not a precise statement of the concern, 
 although that is certainly part of the concern. :-)

> I completely agree with you. But, I guess the sentiment
> has not gone around the IETF.
> The following IPv6 extension headers have been defined since RFC2460
> 
> 135 - Mobility header
> 139 - HIP
> 140 - Shim6
> 141 - WESP

Thanks for giving specific examples.   :-)

I suspect that mostly shows the challenges of coordination among
various IETF WGs, with different charters, living in various
IETF Areas, each undertaking its own work.   

I'm not sure that any IPv6/6MAN WG document will be a 100% solution, 
but I do not object to having a document of some kind that clarifies
the undesirability of more extension headers and re-emphasises the
exiting statements from RFC-2460 (possibly making those statements
even stronger).

> Right now the fact remains that the IPv6 spec allows
> for using a separate header as an option.

...but not where a separate end-to-end header is actually 
useful in a general way...like being received and used 
by the receiving end system.

>  alignment or more efficient parsing."

Thanks for quoting that.

To paraphrase: 
	A separate header can be used  "if and only if" 
	... "the desired action is" ... "to discard the packet".

That narrow exception from the general prohibition applies only
to extension headers that are not generally useful, since they
can only trigger an error response.

The bit you didn't quote already says that all other uses 
(i.e. something generally useful & with an end-to-end nature) 
needs to be done with the IPv6 Destination Options Header,
rather than creating a new extension header with the end-to-end
nature.

Now, there is some evidence that this aspect of RFC-2460
hasn't been fully understood by everyone in the past, 
as you pointed out up top.  

A clarifying statement might help and can't hurt, 
provided it is worded carefully.

> I would be just as happy if such a statement was made
> and could gather consensus in the 6man wg.

That is probably simpler and easier.  

Another alternative would be to retain your draft, 
but edit it along the lines I suggested earlier,
whereby explicit language prohibiting creation of new 
extension headers that have either (a) hop-by-hop 
or (b) end-to-end nature is added in.

I really appreciate your open-mindedness on this.

Cheers,

Ran

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Thu, 18 Nov 2010 01:09:32 +0100

>doesn't apply across the entire IETF.

But then already existing implementiation cannot skip then and must drop the
packet. I get all these reasons not to include GIEH, these are fine and
understandable. But what is the main cause to reject this I-D? There are no
real disadvantage and no overhead but opens the possibility to use the vanilla
extension header mechanism.

Similar to one of your previous emails:

Nobody can see what will happend in the future, what about CONEX where the
signaling posses hop-by-hop _and_ end-to-end characteristic? Did somebody
thought about CONEX and the required feedback five years back? (the example is
a little bit artificial, but it should point to the fact that nobody knows what
will be happend in the next couple of decades).

Cheers, Hagen

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 17 Nov 2010 19:37:54 -0500

On 17  Nov 2010, at 19:09 , Hagen Paul Pfeifer wrote:
> But what is the main cause to reject this I-D?

I am very very sorry, but if the issues aren't clear by now, 
with so many explanations from so many people, then I really 
don't know how to help one understand.

> There are no real disadvantage...

Untrue, see list discussion for several issues.

To pick an arbitrary note from earlier today, see Joel H's 
note about how the current I-D violates RFC-2460...

> and no overhead but opens the possibility to use the vanilla

We already have vanilla mechanisms in the IPv6 Destination
Options and IPv6 Hop-by-Hop Options headers.  We should 
use them.

I've already said that if folks want to define a header
for the entirely theoretical case that a new extension 
has NEITHER the Hop-by-Hop NOR the end-to-end property, 
then that proposed header and specification needs to be 
extremely narrowly scoped -- and that specification 
MUST require use of the existing two headers 
if they can *in any way* be used instead.

(I really hope we can stop looping, and instead move on
to discuss what a path forward might look like. :-)

Yours,

Ran

---

From: "Hing-Kam (Kam) Lam" <[email-masked]>
Date: Thu, 18 Nov 2010 06:52:33 +0530

> Options and IPv6 Hop-by-Hop Options headers.  We should

Surprising, we already have work being proposed in IETF which
encourages deprecating Hop-by-Hop options.

https://datatracker.ietf.org/doc/draft-krishnan-ipv6-hopbyhop/?include_text=1

Kam

---

From: james woodyatt <[email-masked]>
Date: Wed, 17 Nov 2010 18:50:08 -0800

On Nov 15, 2010, at 11:02, RJ Atkinson wrote:
> ** The assumption of this draft is that there exists some IP option type that is NEITHER (a) hop-by-hop nor (b) end-to-end in nature.
> 
> I have never heard of such an option, but if someone can provide a concrete example I'm eager to hear about it.

My expired I-D.woodyatt-ald defines a new ICMPv6 message code for Listener Notification packets.  If this draft were passed, then I could revise it to also define a Firewall Alert option, which would be neither hop-by-hop nor destination-oriented, as firewalls are not necessarily either hosts or routers.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: "Hing-Kam (Kam) Lam" <[email-masked]>
Date: Thu, 18 Nov 2010 22:33:45 +0530

In addition to this, what about cases where the end node does not know
how to process an option given in the destination header - this could
happen when some new destination option is being introduced and not
all boxes are upgraded to understand that? The current proposal
provides some extension flags that would help in such scenarios.

Kam

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 18 Nov 2010 16:13:21 -0500

Hi Ran,

> or (b) end-to-end nature is added in.

You said that, in your implementation, it is easier for the hardware to 
parse a hop-by-hop or destination options rather than an extension 
header. But this view is not something I have ever seen expressed in the 
past. In fact I have heard exactly the opposite view expressed by other 
vendors (and this matches my experience coding them on a network 
processor fast path) and that was the inspiration for this draft.

I think this is the bone of contention. If we can quantify the efforts 
in one way or another, there will be no ambiguity going forward.

> I really appreciate your open-mindedness on this.

No problems. At the end, all we want is a defined extension mechanism 
for implementations to follow.

Thanks
Suresh

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 18 Nov 2010 19:17:52 -0500

On 18  Nov 2010, at 16:13 , Suresh Krishnan wrote:
> You said that, in your implementation,

I don't have an implementation.  I'm an independent consultant,
primarily to folks who happen to operate some large IP networks.
In that position, I have NDAs in place not only with my clients,
but also with some organisations that work with my clients.  

> it is easier for the hardware to parse a hop-by-hop or
> destination options rather than an extension header.

That is NOT what I said.

What I said was that:
	MULTIPLE vendors have already shipped and deployed
	routers that already contain silicon that can parse/
	parse past IPv6 optional headers in hardware at wire-speed.

The key word above is:	MULTIPLE

	My understanding is that routers with these capabilities
	in the silicon are already deployed in multiple large
	IP networks, and that some operational networks rely
	on that capability (e.g. to be able to apply ACL rules
	based on transport-layer information, such as transport
	protocol, transport port numbers).

	Adding any extension header, other than an option carried
	within the existing IPv6 Destination Options header or
	the IPv6 Hop-by-Hop Options header, breaks that important
	operational capability.  We all ought to try really hard
	to avoid breaking deployed standards-compliant IPv6 networks.

Yours,

Ran

---

From: james woodyatt <[email-masked]>
Date: Thu, 18 Nov 2010 17:19:27 -0800

On Nov 18, 2010, at 16:17, RJ Atkinson wrote:
> 
> Adding any extension header, other than an option carried within the existing IPv6 Destination Options header or the IPv6 Hop-by-Hop Options header, breaks that important operational capability. We all ought to try really hard to avoid breaking deployed standards-compliant IPv6 networks.

This sounds like a topic for an important, but so far unwritten, Informational draft.  An alternative approach to addressing the problems that motivated this draft would be if RFC 2460 could be revised or updated somehow to reflect an IETF consensus, assuming one could be found, to the effect that no further IPv6 extension header types are expected to be defined for the rest of the operational lifetime of the IPv6 standard.