Subject: Extracting the 5-tuple from IPv6 packets

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Apr 2010 10:26:08 +1200

Hi,

Common practice in network monitoring and in QoS technologies
is to identify a flow of packets by the 5-tuple
{source address, dest address, source port, dest port, protocol #}.
This is relatively trivial at line speed in IPv4 since
these things are at fixed locations in the header. But in IPv6,
the protocol number is at the end of a linked list of "next
headers." Even if the normal case is only one item in the linked
list, any implementation (hardware or software) that extracts
the 5-tuple has to follow the linked list to the end.

As Mark Smith said in relation to draft-carpenter-6man-flow-update-02

>> Secondly, for IPv6 packets with a number of extension headers before
>> the transport layer header, I think this rule could impact forwarding
>> performance. While I'm not sure if it is that practical, however it'd
>> be good if flow classification could be done using only fixed headers
>> in the IPv6 packet, or a fixed portion of the fixed header bits.

The problem is, only the protocol number is diagnostic of an individual
flow. The earlier next headers are not guaranteed to be the same for
all packets in a transport session, and they might be the same for packets
in different transport sessions between the same two hosts.

So it seems to me that we are stuck with identifying IPv6 flows by
the 5-tuple, even though it means following the linked list to the
end. Or we can forget about identifying individual transport flows,
and identify all traffic between the same two hosts via the 4-tuple
{source address, dest address, source port, dest port}.

Or we can strongly recommend that all hosts set the flow label, so
that we can use the 3-tuple {source address, dest address, flow label}.

What do people think?

-- 
Regards
   Brian Carpenter

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Wed, 14 Apr 2010 15:42:32 -0700

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian E Carpenter
Sent: Wednesday, April 14, 2010 6:26 PM
To: 6man
Cc: Nevil Brownlee
Subject: Extracting the 5-tuple from IPv6 packets

Hi,

Common practice in network monitoring and in QoS technologies is to
identify a flow of packets by the 5-tuple {source address, dest address,
source port, dest port, protocol #}.
This is relatively trivial at line speed in IPv4 since these things are
at fixed locations in the header. But in IPv6, the protocol number is at
the end of a linked list of "next headers." Even if the normal case is
only one item in the linked list, any implementation (hardware or
software) that extracts the 5-tuple has to follow the linked list to the
end.

The problem is, only the protocol number is diagnostic of an individual
flow. The earlier next headers are not guaranteed to be the same for all
packets in a transport session, and they might be the same for packets
in different transport sessions between the same two hosts.

So it seems to me that we are stuck with identifying IPv6 flows by the
5-tuple, even though it means following the linked list to the end. Or
we can forget about identifying individual transport flows, and identify
all traffic between the same two hosts via the 4-tuple {source address,
dest address, source port, dest port}.

[Senthil] In order to get to the port numbers you would still have to
traverse the extension headers and in the process you would identify the
protocol too, isnt that right?

Or we can strongly recommend that all hosts set the flow label, so that
we can use the 3-tuple {source address, dest address, flow label}.

[Senthil] That would be very useful if we can achieve that.

Senthil

What do people think?

--
Regards
   Brian Carpenter

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

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 14 Apr 2010 16:03:10 -0700

Hi Brian,

> that we can use the 3-tuple {source address, dest address, flow label}.
Using a 3-tuple helps in stateless firewalls/ middle boxes/ ECMP,
which cannot/ do-not reassemble all fragments. The 5-tuple is not
available for fragments.

Similarly IPsec has similar issues when selectors are 5-tuples, that
is why there are special cases for how fragments are to be handled. We
had a discussion on this in 2006:

http://www.ops.ietf.org/lists/v6ops/v6ops.2006/threads.html#00045

Thanks,
Vishwas

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Apr 2010 11:11:15 +1200

> protocol too, isnt that right?

Oh my yes! How embarassing, but it makes the problem even worse.

Regards
   Brian Carpenter

---

From: Bob Hinden <[email-masked]>
Date: Wed, 14 Apr 2010 16:16:44 -0700

Brian,

> the 5-tuple has to follow the linked list to the end.

Do we have any data on what percentage of packets have the next header a transport header vs. something else?  It would be good to know how often it's the non-trivial case.

I agree that an implementation will have to know how to at least check what the next header is.  

> that we can use the 3-tuple {source address, dest address, flow label}.

That would make a lot of sense to me.  It would also have an advantage of allowing a set of TCP connections between two hosts to be associated as a single flow where the hosts wanted them to be treated in the same manner.  It's hard to do that with IPv4 as the port numbers will be different for each TCP connection.

Bob

---

From: james woodyatt <[email-masked]>
Date: Wed, 14 Apr 2010 17:58:54 -0700

> What do people think?

I think this topic reminds me of <http://tools.ietf.org/html/draft-krishnan-ipv6-exthdr>.

  "This document proposes a new family of IPv6 extension headers that
   will be encoded in a consistent format so that it is possible for
   intermediate nodes to skip over unknown extension headers and
   continue to further process the header chain if they so desire."

And look: it's expired again.

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

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 14 Apr 2010 21:13:07 -0400

> which cannot/ do-not reassemble all fragments. The 5-tuple is not

using only the 3 tuple also loses you some granularity in your ecmp
decision process... I'm not sure it's a good plan to use the flow
label for something it's explicitly not supposed to be used for, and I
don't know that you can get enough granularity with just these 3
pieces of 'randomness' to has flows out across wide ecmp paths.

More data for the hash seems better.

-Chris

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 14 Apr 2010 21:17:03 -0400

> I agree that an implementation will have to know how to at least check what the next header is.

most high-end routers today that do v6 only deal with a limited number
(3 or so) extension headers anyway, so they've figured out how to do
line-rate 100-ge with ipv6 ...

this is, also, one of the reason whenever someone says: "We should
make an extension header for this!" I say: "Extension headers are the
devil, they should all die a horrible death, don't add to an already
horrendous problem."

> That would make a lot of sense to me.  It would also have an advantage of allowing a set of TCP connections between two hosts to be associated as a single flow where the hosts wanted them to be tre…

This seems fine, until the 2 sessions are larger (combined) than parts
of the pathways between the 2 hosts. ECMP/LAG are nice tools, and
necessary in today's internet, if you can't hash the flows reasonably
and 2 large flows end up hashed to the same smaller link bad things
for the hosts' traffic will happen.

-Chris

---

From: Mohacsi Janos <[email-masked]>
Date: Thu, 15 Apr 2010 09:05:06 +0200 (CEST)

On Thu, 15 Apr 2010, Brian E Carpenter wrote:

> these things are at fixed locations in the header.

I disagree. The source port and destination port is not in fixed location 
since IPv4 option might have variable lengths.

> that we can use the 3-tuple {source address, dest address, flow label}.

Agreed. We should avoid extension header porcessing at all price.

 	Janos Mohacsi

---

From: Simon Perreault <[email-masked]>
Date: Thu, 15 Apr 2010 09:50:00 -0400

> that we can use the 3-tuple {source address, dest address, flow label}.

It would be easy for an attacker to put garbage in the flow label to 
trick the QoS. So you couldn't use the flow label from hosts you don't 
trust, which is most of them nowadays.

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

---

From: Francis Dupont <[email-masked]>
Date: Thu, 15 Apr 2010 16:00:24 +0200

In your previous mail you wrote:

   any implementation (hardware or software) that extracts
   the 5-tuple has to follow the linked list to the end.
   
=> and in a rare case ports are not in the first fragment...

=> the flow label was designed for it, wasn't it? And I can't see
a problem with recommending to set the flow label to get a "better" QoS.
BTW this simplifies fragment classifying too.

Regards

[email-masked]

---

From: Mohacsi Janos <[email-masked]>
Date: Thu, 15 Apr 2010 16:32:22 +0200 (CEST)

On Thu, 15 Apr 2010, Simon Perreault wrote:

> It would be easy for an attacker to put garbage in the flow label to trick 
> the QoS. So you couldn't use the flow label from hosts you don't trust, which 
> is most of them nowadays.

So as put garbage to src and dst port. If BCP-38 network ingres filter is 
implemented, then not so easy.....

 	Best Regards,
 		Janos Mohacsi

---

From: Simon Perreault <[email-masked]>
Date: Thu, 15 Apr 2010 10:36:10 -0400

On 2010-04-15 10:32, Mohacsi Janos wrote:
> So as put garbage to src and dst port.

Not as easy because a host often has no control on the destination port.

Google won't talk to me unless I put 80 in there.

Simon

---

From: Mohacsi Janos <[email-masked]>
Date: Thu, 15 Apr 2010 16:38:58 +0200 (CEST)

> Google won't talk to me unless I put 80 in there.

Why cope with QoS if somebody is sending packets to black-hole?

Janos

---

From: Simon Perreault <[email-masked]>
Date: Thu, 15 Apr 2010 10:49:35 -0400

> Why cope with QoS if somebody is sending packets to black-hole?

I don't understand your question, but here's an example use case of the 
attack I'm suggesting:

I want to evade an SFQ QoS for a single flow. If the QoS is based on the 
flow field, I can just put random values in the flow field so that my 
packets appear to come from multiple flows, which will let me get better 
throughput.

Many other examples come to mind...

This usage of the flow field would need to be treated just like the DSCP 
field. Maybe you can use it in some applications, not in others. But a 
recommendation that all hosts on the Internet set it would be pointless 
if intermediate networks can't or won't use it.

Simon

---

From: Vishwas Manral <[email-masked]>
Date: Thu, 15 Apr 2010 07:59:46 -0700

Hi,

I agree with Francis that there is the issue of the transport headers
not being present in the first fragment itself. In IPv4 the minimum
fragment size is 64 which means the first fragement has the header
(even when options are present).

We have a draft to take care of this for IPv6:
http://tools.ietf.org/html/draft-manral-v6ops-tiny-fragments-issues-03

A link to the tiny Fragment attack
http://www.javvin.com/networksecurity/TinyFragmentAttack.html

I am also working with Suresh Krishnan to get a new version of this draft out.

Thanks,
Vishwas

---

From: Mohacsi Janos <[email-masked]>
Date: Thu, 15 Apr 2010 17:11:43 +0200 (CEST)

On Thu, 15 Apr 2010, Simon Perreault wrote:

> I want to evade an SFQ QoS for a single flow. If the QoS is based on the flow 
> field, I can just put random values in the flow field so that my packets 
> appear to come from multiple flows, which will let me get better throughput.

Then we are speaking two different beasts:
- you are speaking about a policed and/or rate limited flows
- I was speaking about a preferential treatment of sent flows

> recommendation that all hosts on the Internet set it would be pointless if 
> intermediate networks can't or won't use it.

That is why we are thinking of different models:
Diffserv like architecture for flow field.

Do we need more classes in a backbone than available in the current 
DSCP/diffserv model?

In the diffserv model you are rewriting DSCP values at the administrative 
domains. Do we want to rewrite flow fields similarly? or is it e2e?

Also you mark/remark packets in you aggregation network according to the 
services and origin. Do we want to change flow filed?

Flow field is a tool for network operators to better classification or 
more e2e tool for applications?

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 15 Apr 2010 11:22:09 -0400

There seem to be two separate things going on here, and they appear to 
be getting mixed.

The first thing is the notion that the host should set a non-zeero value 
into the flow label.  They should do so with the constraint that 
different packets which are part of the same flow MUST have the same 
flow label.  And flows which the end host is willing to have treated 
(even if treated may mean simply in terms of which link in a LAG or ECMP 
selection is used) differently may have different flow labels.

However, a network can not give QoS treatment purely on the basis of 
source and dest IPv6 address plus flow label.  There simply is not 
enough information.  A client provided flow label is not a DSCP code point.

So networks that want to do QoS will have to do something additional. 
What?  That depends upon what they want to do.  I would hope that 
whatever they do it does not destroy the granularity of the flow label 
as described above.

If we can count on hosts setting the flow label with suitable 
granularity, then we can use the flow label (plus src and dest IPv6 
address) in our ECMP and LAG hashes without having to look for protocol 
and port numbers.  That avoids much complexity related to next headers 
and similar problems.  And it is not subject to an attack by someone 
mis-setting the flow label field.

The one obvious conclusion here is that if we want hosts to actually set 
flow labels, then we are largely preempting network modification of 
those flow labels.  Whatever setting we want to allow, it would have to 
preserve the granularity of the original flow label variation.  Which is 
pretty hard.
Now, I personally don't quite understand what the "modified flow label" 
proposal is for.  As such, I don't mind giving it up.  Particularly if I 
get cleaner packet processing for the normal case as a result.

Yours,
Joel

Mohacsi Janos wrote:
>> I don't understand your question, but here's an example use case of 
>> the attack I'm suggesting:
>>
>> I want to evade an SFQ QoS for a single flow. If the QoS is based on 
>> the flow field, I can just put random values in the flow field so that 
>> my packets appear to come from multiple flows, which will let me get 
>> better throughput.
> 
>> This usage of the flow field would need to be treated just like the 
>> DSCP field. Maybe you can use it in some applications, not in others. 
>> But a recommendation that all hosts on the Internet set it would be 
>> pointless if intermediate networks can't or won't use it.
> 
> In the diffserv model you are rewriting DSCP values at the 
> administrative domains. Do we want to rewrite flow fields similarly? or 
> is it e2e?
>

---

From: Rémi Després <[email-masked]>
Date: Thu, 15 Apr 2010 17:35:46 +0200

> that we can use the 3-tuple {source address, dest address, flow label}.

In view of Mark's remark about the impossibility for routers to identify 5-tuples of all IPv6 packets, I tend to think this is the right way to go.

But then another requirement of RFC 3697 should be relaxed:
- The RFC says: "To avoid accidental Flow Label value reuse, the source node SHOULD select new Flow Label values in a well-defined sequence"
- This implies a stateful assignment of flow labels.

A stateless alternative, where flow label values are just a hash of the 5-tuple (or 3-tuple if alone to be available), should IMHO be permitted, and not less recommended than the stateful well-defined sequence:
- It permits to compute flow labels *on a per datagram basis*, just before their being transformed into packets.
- Hash functions may be different in different hosts (advices may be welcome, but there is no need to standardize)

Regards,
RD

---

From: Steven Blake <[email-masked]>
Date: Thu, 15 Apr 2010 11:45:52 -0400

On Thu, 15 Apr 2010 11:22:09 -0400, "Joel M. Halpern"
<[email-masked]>

> get cleaner packet processing for the normal case as a result.

+1

// Steve

---

From: Mohacsi Janos <[email-masked]>
Date: Thu, 15 Apr 2010 17:59:04 +0200 (CEST)

On Thu, 15 Apr 2010, Joel M. Halpern wrote:

> There seem to be two separate things going on here, and they appear to be 
> getting mixed.
>
> The first thing is the notion that the host should set a non-zeero value into 
> the flow label.  They should do so with the constraint that different packets 
> which are part of the same flow MUST have the same flow label.  And flows 
> which the end host is willing to have treated (even if treated may mean 
> simply in terms of which link in a LAG or ECMP selection is used) differently 
> may have different flow labels.
>
> However, a network can not give QoS treatment purely on the basis of source 
> and dest IPv6 address plus flow label.  There simply is not enough 
> information.  A client provided flow label is not a DSCP code point.
>
> So networks that want to do QoS will have to do something additional. What? 
> That depends upon what they want to do.  I would hope that whatever they do 
> it does not destroy the granularity of the flow label as described above.
>
> If we can count on hosts setting the flow label with suitable granularity, 
> then we can use the flow label (plus src and dest IPv6 address) in our ECMP 
> and LAG hashes without having to look for protocol and port numbers.  That 
> avoids much complexity related to next headers and similar problems.  And it 
> is not subject to an attack by someone mis-setting the flow label field.

I understand similarly as you. Best Regards,
 			Janos Mohacsi

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 15 Apr 2010 12:08:04 -0500

> From: [email-masked] [mailto:[email-masked]] On 

> those flow labels.

Looks to me like this is true as well. In Brian's I-D 02, an edge router at the destination side would be able to tell whether the flow label had been set by a source host or an intervening router. So, that makes flow labels unusable for end-to-end QoS.

Question: if we don't want to specify different flow label ranges, e.g. to show whether the lable was set by a host vs the ISP's network, then isn't there a combination of flow label and traffic class that could accomplish this? Something like this could be an option, instead of using the traditional 5-tuples?

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 15 Apr 2010 12:12:46 -0500

I meant,

"In Brian's I-D 02, an edge router at the destination side would *NOT* be able to tell whether the flow label had been set by a source host or an intervening router."

Bert

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Manfredi, Albert E
Sent: Thursday, April 15, 2010 1:08 PM
To: Joel M. Halpern
Cc: [email-masked]
Subject: RE: Extracting the 5-tuple from IPv6 packets

> flow labels, then we are largely preempting network modification of 

Looks to me like this is true as well. In Brian's I-D 02, an edge router at the destination side would *not* be able to tell whether the flow label had been set by a source host or an intervening router. So, that makes flow labels unusable for end-to-end QoS.

Bert

---

From: Shane Amante <[email-masked]>
Date: Thu, 15 Apr 2010 11:37:46 -0600

Bert,

> Question: if we don't want to specify different flow label ranges, e.g. to show whether the lable was set by a host vs the ISP's network, then isn't there a combination of flow label and traffic cl…

Or, better, (re-)acknowledge RFC 2474, a.k.a. DiffServ, is the sole go forward mechanism for CoS treatment, meaning PHB's/treatments are to be based only on the IP Traffic Class field.  The industry seems to have at least implicitly acknowledged that more granular, IntServ-type signaling (perhaps, the original intent of the flow-label?) aren't scalable in the IPv4 Internet and, likely, IPv6 Internet as well.  Thus, we should move on to a more appropriate use of a IPv6 flow-label?

-shane

---

From: Simon Perreault <[email-masked]>
Date: Thu, 15 Apr 2010 13:40:15 -0400

On 2010-04-15 11:22, Joel M. Halpern wrote:
> source and dest IPv6 address plus flow label. There simply is not enough

My point with comparing this proposal with DSCP was that you cannot 
trust a host to do it in good faith in both cases. With DSCP, since 
hosts can trivially set the "fast bit", networks filter it at the edge. 
Same goes for the flow label if used for QoS.

Other than that, I agree with your assessment.

Thanks,
Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Apr 2010 10:22:32 +1200

Simon,

> Same goes for the flow label if used for QoS.

If used as an *encoded* field for QoS. Exactly. That's why the idea
can be boiled down to:

For generic use, set a pseudo-random label per flow.
  (forging it won't help you very much ;-)
For local use, set an *encoded* value meaning whatever you want,
  but don't trust such values at the border.

I think we can simplify the proposal further after this discussion.
And then the decision is whether we want to allow the local use
case. I assure you there are people who want it.

    Brian

---

From: Rémi Després <[email-masked]>
Date: Fri, 16 Apr 2010 11:44:23 +0200

Hi all,

Thanks to James for the pointer to draft-krishnan-ipv6-exthdr-08.

I don't know exactly what the status of draft-krishnan-ipv6-exthdr-08 is today, but it this proposal has IMHO to become quickly a standard-track RFC:
- The ability of skipping an extension header in a node that doesn't know it is clearly needed. 
- This need should have been satisfied in the original IPv6 specification.

I therefore support that this draft should become asap a 6man WG document.

Regards,
RD

---

From: james woodyatt <[email-masked]>
Date: Fri, 16 Apr 2010 11:58:08 -0700

> I don't know exactly what the status of draft-krishnan-ipv6-exthdr-08 is today, but it this proposal has IMHO to become quickly a standard-track RFC:

The draft was presented most recently at IETF-72 Dublin.

From the minutes <http://tools.ietf.org/wg/6man/minutes?item=minutes72.html>:
>> 
>> 	  Extension Headers, Suresh Krishnan
>>           ==================================
>>           Document: draft-krishnan-ipv6-exthdr-03.txt
>>           Slides: Extension Headers, 6man-6.pdf
>>           
>>           Suresh reported on the update to the extension headers draft.
>>           He addressed all comments received except for the "who is
>>           going to use extension headers?" comment. The point of this
>>           document is "if you use them, this is how you do it". A number
>>           of issues were addressed in the update. The remaining open
>>           issue is backwards compatibility. Extension headers may alter
>>           processing. A packet cannot be processed by older
>>           implementations that don't understand the extension header.
>>           The standard approach for dealing with this issue is
>>           recommending that implementations do not process
>>           unrecognized extension headers. There was a question about
>>           who is responsible for the IPv6 API?  It is currently an
>>           informational RFC. It falls within the domain of the POSIX
>>           standards community, but they have not taken it up yet. We can
>>           only give recommendations to the POXIX community. Brian
>>           Haberman concluded the discussion by asking Suresh to revise
>>           the document and ask the mailing list for consensus.

[continuing quote from Rémi]
> - This need should have been satisfied in the original IPv6 specification.

I was present in the room for the discussion.  I don't think the audience recognized as clear a need for this draft as the nominal authors did.  The meeting adjourned moments later without the working group taking up the draft as a work item.

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 16 Apr 2010 15:43:19 -0400

Hi Remi,

> I therefore support that this draft should become asap a 6man WG document.

As James chimed in, we let the draft expire because there was no clear 
consensus in the WG as to the need to define new extension headers. We 
have addressed all the comments received from the WG in the last version 
the draft. We can refresh the draft and request the chairs for adoption, 
provided we see somebody trying to define or seeing a need to define a 
new extension header.

Cheers
Suresh

---

From: james woodyatt <[email-masked]>
Date: Fri, 16 Apr 2010 13:28:42 -0700

On Apr 16, 2010, at 12:43, Suresh Krishnan wrote:
> 
> As James chimed in, we let the draft expire because there was no clear consensus in the WG as to the need to define new extension headers. We have addressed all the comments received from the WG in the last version the draft. We can refresh the draft and request the chairs for adoption, provided we see somebody trying to define or seeing a need to define a new extension header.

In other words, it appears to be the sense of the working group that the presence of an unrecognized next header value currently precludes the possibility of identifying whether there is an unrecognized extension header interposed between the IPv6 header and the upper-layer transport header.  It's important to note that 'unrecognized' does not mean 'undefined' here-- it just means 'undefined when the packet analyzer was made' which is not precisely the same thing.

Going back to Mr. Carpenter's message about extracting the 5-tuple from IPv6 packets, it seems pretty clear that the logical consequence of the above is that we have only two real alternatives available: A) strongly recommend that all hosts set the flow label, so that we can use the 3-tuple {source address, dest address, flow label}, B) change our mind about whether we need a standard format for generic extension headers, so that we have some hope of always being able to find the 5-tuple even when we cannot process the interposing extension header.

For the record, I *strongly* prefer option A over option B.  On the other hand, if we go with option B, then that will allow greater flexibility in using RFC 3692 protocol numbers in the face of stateful packet filters like those described in I-D.ietf-v6ops-cpe-simple-security, making them less of an interference than they would otherwise be.

---

From: Brian Haberman <[email-masked]>
Date: Fri, 16 Apr 2010 16:57:09 -0400

On 4/16/10 4:28 PM, james woodyatt wrote:
>> As James chimed in, we let the draft expire because there was no
>> clear consensus in the WG as to the need to define new extension
>> headers. We have addressed all the comments received from the WG in
>> the last version the draft. We can refresh the draft and request
>> the chairs for adoption, provided we see somebody trying to define
>> or seeing a need to define a new extension header.
> 
> In other words, it appears to be the sense of the working group that
> the presence of an unrecognized next header value currently precludes
> the possibility of identifying whether there is an unrecognized
> extension header interposed between the IPv6 header and the
> upper-layer transport header.  It's important to note that
> 'unrecognized' does not mean 'undefined' here-- it just means
> 'undefined when the packet analyzer was made' which is not precisely
> the same thing.
> 
> Going back to Mr. Carpenter's message about extracting the 5-tuple
> from IPv6 packets, it seems pretty clear that the logical consequence
> of the above is that we have only two real alternatives available: A)
> strongly recommend that all hosts set the flow label, so that we can
> use the 3-tuple {source address, dest address, flow label}, B) change
> our mind about whether we need a standard format for generic
> extension headers, so that we have some hope of always being able to
> find the 5-tuple even when we cannot process the interposing
> extension header.
> 
> For the record, I *strongly* prefer option A over option B.  On the
> other hand, if we go with option B, then that will allow greater
> flexibility in using RFC 3692 protocol numbers in the face of
> stateful packet filters like those described in
> I-D.ietf-v6ops-cpe-simple-security, making them less of an
> interference than they would otherwise be.

Option A also allows for the handling of encrypted packets where the
transport layer port numbers can't be found regardless.

Regards,
Brian H.

---

From: Stig Venaas <[email-masked]>
Date: Fri, 16 Apr 2010 17:38:12 -0700

Suresh Krishnan wrote:
>> I don't know exactly what the status of draft-krishnan-ipv6-exthdr-08 
>> is today, but it this proposal has IMHO to become quickly a 
>> standard-track RFC:
>> - The ability of skipping an extension header in a node that doesn't 
>> know it is clearly needed. - This need should have been satisfied in 
>> the original IPv6 specification.
>>

It's clear to me that this draft is needed. Ever since I wrote some
packet analyzer code many years ago and realized I couldn't handle
unknown IPv6 options in a good way (that is, ignoring them and still
finding the transport header).

I support adoption.

Stig

---

From: Rémi Després <[email-masked]>
Date: Tue, 20 Apr 2010 15:52:34 +0200

Le 16 avr. 2010 à 21:43, Suresh Krishnan a écrit :

>> - The ability of skipping an extension header in a node that doesn't know it is clearly needed. - This need should have been satisfied in the original IPv6 specification.
> As James chimed in, we let the draft expire because there was no clear consensus in the WG as to the need to define new extension headers.

Your draft, which has authors from Ericsson, Cisco, Google, Symantec, covers per se a wide spectrum of industrial perspectives. 

What would be needed to differ its adoption would be, IMHO, arguments showing that it mighgt be harmful.
AFAIK, no such argument exists.
On the contrary, Stig Venaas wrote on 2010-04-16:
"It's clear to me that this draft is needed. Ever since I wrote some
packet analyzer code many years ago and realized I couldn't handle
unknown IPv6 options in a good way (that is, ignoring them and still
finding the transport header)."

> We have addressed all the comments received from the WG in the last version the draft.
> We can refresh the draft and request the chairs for adoption, provided we see somebody trying to define or seeing a need to define a new extension header.

Waiting for this new extension header to be found useful would be IMHO a DESIGN MISTAKE: if and when such an extension is found useful, it will be too late because ALL codes that look for ports will need to be upgraded before deployment of the new extension.

If the 6man chair may accept a resubmission as WG draft in view of the recent discussion on this list (i.e. significant interest expressed, and no objection), this would be the best.
If this isn't possible, your reviving the draft would leave a chance to finally solve a real problem.

Cheers,
RD

---

From: james woodyatt <[email-masked]>
Date: Tue, 20 Apr 2010 09:25:39 -0700

> Waiting for this new extension header to be found useful would be IMHO a DESIGN MISTAKE: if and when such an extension is found useful, it will be too late because ALL codes that look for ports wil…

I think this argues that we should position I-D.krishnan-ipv6-exthdr as an update to RFC 3692 and instruct IANA to reserve two additional numbers for experimental IPv6 extension headers, which we then require to be formatted accordingly, and which we also permit nodes to silently ignore if they do not support processing them.

The general problem of distinguishing extension headers from upper-layer transports by a programmatic method is, I suspect, not worth the trouble that would surely be involved in solving it.

---

From: Rémi Després <[email-masked]>
Date: Tue, 20 Apr 2010 18:56:34 +0200

Hi James,

Using the experimental status seems to me confusing (and why two numbers instead of one?)

If the draft becomes a standard-track RFC, as originally proposed but so far insufficiently supported, we will have all what is needed, simply an cleanly.
I hope this can happen.

Regards,
RD

---

From: james woodyatt <[email-masked]>
Date: Tue, 20 Apr 2010 10:35:06 -0700

> Using the experimental status seems to me confusing (and why two numbers instead of one?)

There are two numbers reserved for protocols, and I was plagued by the hobgoblins of consistency.  I suppose we could assign only one.  Or more than two.  It's a discussion point.

> If the draft becomes a standard-track RFC, as originally proposed but so far insufficiently supported, we will have all what is needed, simply an cleanly.

Okay... how do you propose that IPv6 nodes and/or packet analyzers programmatically distinguish between extension headers and upper-layer transports if they are given only an unrecognized protocol number without access to the online IANA assigned protocol numbers database?

I think if you pull on the threads of that question, you will quickly come to a snarly knot of related problems that are A) difficult, and B) probably not worth solving if you bypass them with a simple update to RFC 3692 as I just proposed.

-----

To reiterate, I think the original motive for bringing this up, extracting 5-tuples from IPv6 packets, is a bad idea.  In general, only some IPv6 packets have 5-tuples, and of those, only a subset can have 5-tuples that packet analyzers can extract, i.e. the rest are encapsulated in ESP or a moral equivalent (and ESP packets have 4-tuples).

Hosts should set flow labels.  They should probably use RFC 2205 if they need fine-grained resource reservations to claw out marginal capacity in under-provisioned networks.  Otherwise, they should ride the best-effort bus like everyone else.

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 20 Apr 2010 18:42:40 -0400

Hi James,

> Okay... how do you propose that IPv6 nodes and/or packet analyzers programmatically distinguish between extension headers and upper-layer transports if they are given only an unrecognized protocol…

Simple. All future IPv6 extension headers will use the same next header 
value (the one allocated for the GIEH). Anything else can be considered 
a unknown upper layer header.

Cheers
Suresh

---

From: james woodyatt <[email-masked]>
Date: Tue, 20 Apr 2010 18:02:02 -0700

On Apr 20, 2010, at 15:42, Suresh Krishnan wrote:
> 
> Simple. All future IPv6 extension headers will use the same next header value (the one allocated for the GIEH). Anything else can be considered a unknown upper layer header.

That's proposed informally in the draft, but it doesn't appear to be formalized in any way, which is why I wasn't sure that it would be safe for packet analyzers to assume they could identify all the extension headers.  (Grmf.  And I'm nominally a co-author on the draft.)

I'd say there are two changes we should make to Section 6, IANA Considerations, in the next revision:

+ instruct IANA to reserve GIEH sub-type values for experimental purposes and cite RFC 3692.

+ instruct IANA to require a *separate* IETF standards action to allow IPv6 extension headers to be numbered from the assigned protocol number database *before* assigning any such numbers to a new extension header.

---

From: Rémi Després <[email-masked]>
Date: Wed, 21 Apr 2010 10:43:55 +0200

> There are two numbers reserved for protocols, and I was plagued by the hobgoblins of consistency.  I suppose we could assign only one.  Or more than two.  It's a discussion point.

In my understanding, the draft needs only one, to be standardized rather than experimented.
I personally sees no reason to change this (see below)

> Okay... how do you propose that IPv6 nodes and/or packet analyzers programmatically distinguish between extension headers and upper-layer transports if they are given only an unrecognized protocol…

If a packet analyzer needs to recognize a protocol above IP:
- It skips all extensions headers specified before 2010, with due knowledge of their individual format.
- It skips all extension headers specified later (they are identified by their common GIEH number in next-header fields that precedes them, and their lengths are found in their common "Hdr Ext Len" fields).
- When it finds a different next-header value, it is that of the protocol above IP.

(Then it can do whatever it has to do on the found protocol above IP, e.g process ports numbers if it is TCP, UDP, DCCP, SCTP, and discard others if it is a stateful translator. Its code no longer needs an update if and when new IP-layer extension headers are introduced in the future.)    

> To reiterate, I think the original motive for bringing this up, extracting 5-tuples from IPv6 packets, is a bad idea.

I agree that this is a bad idea as regards the flow-label discussion, essentially because of what Mark Smith pointed out: this doesn't work on a per packet basis for fragmented IPv6 datagrams.

BUT draft-krishnan-ipv6-exthdr-08 was proposed before this discussion, and with a motivation that still holds on its own, and is sufficient in my understanding to justify its endorsement.

>  In general, only some IPv6 packets have 5-tuples, and of those, only a subset can have 5-tuples that packet analyzers can extract, i.e. the rest are encapsulated in ESP or a moral equivalent (and ESP packets have 4-tuples).
> 
> Hosts should set flow labels.  

Agreed.

This should be IMHO the conclusion of the current discussion on flow labels, BUT provided hosts are explicitly permitted to set flow-label values statelessly for each datagram, with a hash of their 5-tuples.
(RFC 3697 says "To avoid accidental Flow Label value reuse, the source node SHOULD select new Flow Label values in a well-defined sequence", which privileges flow-label assignments that are stateful per connection, a choice significantly more complex than needed.)

Regards,
RD

> They should probably use RFC 2205 if they need fine-grained resource reservations to claw out marginal capacity in under-provisioned networks.  Otherwise, they should ride the best-effort bus like everyone else. 
> 
> --

---

From: Rémi Després <[email-masked]>
Date: Wed, 21 Apr 2010 10:50:10 +0200

Hi Brian,

I wonder what you think of what I answered to James on another discussion thread.

Regards,
RD

Début du message réexpédié :

> De : Rémi Després <[email-masked]>
> Date : 21 avril 2010 10:43:55 HAEC
> À : james woodyatt <[email-masked]>
> Cc : 6man 6man <[email-masked]>
> Objet : Rép : Draft-krishnan-ipv6-exthdr-08 to become asap a 6man WG draft ?
> 
> ...

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Apr 2010 09:17:09 +1200

> I wonder what you think of what I answered to James on another discussion thread.

I agree. I think that particular SHOULD in the RFC is an error. It "SHOULD"
have said something like:

"The source node MUST select new Flow Label values by a method that
prevents unintended Flow Label value reuse."

   Brian

---

From: Rémi Després <[email-masked]>
Date: Thu, 22 Apr 2010 10:08:34 +0200

> prevents unintended Flow Label value reuse."

Yes, that's more appropriate.

Suggesting in addition that a 5-tuple hash can be an easy way to set flow-label values, because it is stateless, would IMHO improve chances that host really set them.
Wold you agree on this too?

RD

---

From: Steven Blake <[email-masked]>
Date: Thu, 22 Apr 2010 13:31:29 -0400

On Thu, 22 Apr 2010 10:08:34 +0200, Rémi Després <[email-masked]>
wrote:

> Suggesting in addition that a 5-tuple hash can be an easy way to set
> flow-label values, because it is stateless, would IMHO improve chances
that
> host really set them.

My reading of "The source node MUST select new Flow Label values by a
method that prevents unintended Flow Label value reuse." would preclude use
of a 5-tuple hash, which could result in coincidental selection of a flow
label value already in-use by another flow.

Do we really want/need to specify a MUST here?  What is wrong with
low-probability, coincidental flow label reuse between flows with different
source/destination address pairs, so long as the values are otherwise
uniformly distributed and unpredictable?

Regards, 

// Steve

---

From: Rémi Després <[email-masked]>
Date: Thu, 22 Apr 2010 20:40:53 +0200

> label value already in-use by another flow.

Well, "unintended" may be taken as permitting the hash (its intent of the hash that two different 5-tuples give in general two different values, with only statistically rare exceptions),  but better words may also be proposed.
In any case, explicitly permitting the 5-tuple hash is IMHO desireble.

Regard,
RD

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 23 Apr 2010 09:25:00 +1200

> In any case, explicitly permitting the 5-tuple hash is IMHO desireble.

Yes. And if that produces identical hashes for two different 5-tuples, then
the lawyer in me says that's "intended" so does not break the MUST.
This needs to be carefully wordsmithed, but I think we are in agreement.

   Brian

---

From: Vishwas Manral <[email-masked]>
Date: Thu, 22 Apr 2010 14:39:40 -0700

Hi Brian,

> This needs to be carefully wordsmithed, but I think we are in agreement.
Though as the size of the 5-tuple is more than when using the 4-tuple
with flow label, it should not be an issue at all.

The ingress can use same flow labels when the it doesn't care if
certain flows go over the same path or not/ or it could use different
flow labels when sending sub-flow traffic over different paths. It
could also use the intelligence to distribute flows with different
labels, which it cannot in case of the 5-tuple as the values cannot be
changed based on flow needs.

Thanks,
Vishwas

---

From: Florian Weimer <[email-masked]>
Date: Fri, 23 Apr 2010 13:28:26 +0200

> these things are at fixed locations in the header.

Only if you ignore IP options.  Of course, IP options have been
operationally deprecated and are typically not forwarded across the
public Internet.

> But in IPv6, the protocol number is at the end of a linked list of
> "next headers." Even if the normal case is only one item in the
> linked list, any implementation (hardware or software) that extracts

As far as I can tell, all extension headers except fragmentation are
deprecated, similar to IP options in IPv4 land.  This should make
extraction much simpler.

>From today's perspective, the IPv6 header design is complete crap.
Maybe it was optimized for software forwarding on in-order CPUs, but
that's distant history now.