Subject: Flow Label

From: [email-masked]
Date: Thu, 3 Jan 2002 11:01:41 -0800 (PST)

Just a quick question from an interested lurker: Are these hums of
acquiescence in response, specifically, to the idea that an originating
node may set the flow label to any value, and that nodes forwarding
packets will leave that value alone?              -- George Mitchell

--------------------------------------------------------------------
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: Keith Moore <[email-masked]>
Date: Thu, 03 Jan 2002 14:51:30 -0500

> packets will leave that value alone?              -- George Mitchell

not quite.  if we someday define how the flow label is to be used, 
originating nodes can follow that spec.  that's not the same thing 
as saying that originating nodes can set the flow label field to 
whatever value they like.

Keith

---

From: "Jim Fleming" <[email-masked]>
Date: Thu, 3 Jan 2002 15:04:08 -0800

----- Original Message ----- 
From: "Keith Moore" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, January 03, 2002 11:51 AM
Subject: Re: Flow Label 

> whatever value they like.

Originating nodes can always set any values to anything they want.
The consensus of the nodes in the network then works to process
what the originating node sets the values to, and the result is observed.
Some people may or may not change the way they set the values,
based on the observed results.

In summary, people will route around the damage and gravitate
to solutions that work.

Jim Fleming
2002:[IPv4]:000X:03DB
http://www.IPv8.info

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 03 Jan 2002 14:51:00 -0500

Hi George,

Yes, we are "humming" in agreement to the proposal that we
replace section 6 of RFC 2460 with the following text:

 > The 20-bit Flow Label field in the IPv6 header MAY be set by a 
 > source to label sets of packets. Nodes that do not support 
 > the Flow Label field MUST set the field to zero when originating a 
 > packet, and MUST ignore the field when receiving a packet. All routers 
 > MUST pass the field on unchanged when forwarding a packet. 
 > 
 > This specification does not further define the meaning of the 
 > Flow Label. 
 > 

And that we delete Appendix A from RFC 2460.

Actually, we probably won't update RFC 2460.  We'll probably
just publish a separate RFC that updates 2460.

Margaret

---

From: "Jim Fleming" <[email-masked]>
Date: Thu, 3 Jan 2002 18:01:52 -0800

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Sent: Thursday, January 03, 2002 11:01 AM
Subject: Flow Label

> packets will leave that value alone?              -- George Mitchell

Keep in mind that there is not really a 20-bit Flow Label.
Go read the code. The BSD code is a common reference.

What you really have is a 64-bit "control field" and that is
broken into a 32-bit flow, and another 32 bit field that
has a 16-bit length, 8-bit Protocol, and 8-bit TTL. The
32-bit flow has 4-bits of Version, 8-bits of TOS, and ????
The ???? is alignment to the 32-bit boundary, it happens
to be 20 bits. The code should be easy to fix up to make
something more useful.

Jim Fleming
2002:[IPv4]:000X:03DB
http://www.IPv8.info

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 04 Jan 2002 11:41:50 +0100

And, truth in advertising, we have heard two dissenting
views:

a) that the field should be defined as MUST BE ZERO, i.e.
the MAY clause below gets deleted

b) that the 3rd MUST should be SHOULD, i.e. immutability should
be default instead of mandatory.

   Brian

---

From: Robert Elz <[email-masked]>
Date: Fri, 04 Jan 2002 20:17:56 +0700

Date:        Fri, 04 Jan 2002 11:41:50 +0100
    From:        Brian E Carpenter <[email-masked]>
    Message-ID:  <[email-masked]>

  | b) that the 3rd MUST should be SHOULD, i.e. immutability should
  | be default instead of mandatory.

I'm not sure I believe the 100% immutable argument, but I certainly
wouldn't deviate from it that far.  That is, I'd keep it at MUST
with just a very precise exception (which amounts to when the sender
has specifically notified the router that the field may be changed).

I'm pretty sure I'd never want to actually use the exception, except
possibly to explicitly say "Do what you like" (or if you like, "this
field isn't being used") - but I can't see what harm would be done
by leaving that small exception available.   In practical cases,
explicitly notifying routers about specific flows where the label
may be altered is most likely too difficult to ever happen, so this would
probably just amount to allowing a single router to change the field
from a sender's explicit "I don't care" into some other value.

kre

---

From: Randy Bush <[email-masked]>
Date: Fri, 04 Jan 2002 07:35:50 -0800

> the MAY clause below gets deleted

fwiw, i withdraw my dissent

randy

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 04 Jan 2002 09:33:03 -0800

Hello Brian,

> the MAY clause below gets deleted

I would say that MAY is a lot better.  It suggests the truth,
which is that people are going to try to figure out ways to
use the flow label.  It also motivates immutability.  Otherwise,
it is possible that some router vendors could simply zero out
the field -- if it MUST BE ZERO, then zeroing it preserves
immutability...  We wouldn't want that.

> be default instead of mandatory.

Any future technique for using the flow label would, if it violates
immutability, be viewed as obsoleting this part of the specification
anyway.  So I would hope for a MUST here.  Language suggesting that
it is merely the default would allow for a tunable know in the user
interface labeled thusly:
	"Flow Label treatment (default: do not change): "
to be filled in by the system administrator.  Possible other values
selectable by the operator could be "randomize", "ones-complement",
"store current time", ... (?).  I don't know why anyone would do
this, but I think we ought to be pretty clear about prohibiting it
at least for now.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 04 Jan 2002 09:40:45 -0800

Typo alert in my last message:

"Charles E. Perkins" wrote:

>    ...   So I would hope for a MUST here.  Language suggesting that
                                                     knob
> interface labeled thusly:
           ...

Regards,
Charlie P.

---

From: "Subrata Goswami" <[email-masked]>
Date: Fri, 4 Jan 2002 09:55:12 -0800

The wording for immutability aside, to really enforce immutability
of the Flow Label , there must be a mechanism to verify that the
Flow Label has not been changed. As can be seen from the ICV computation
for IPv6 (RFC2402) even AH considers Flow  label to be mutable. Hence there
needs to be a new IPv6 header option for Flow Label immutability.

3.3.3.1.2  ICV Computation for IPv6

3.3.3.1.2.1  Base Header Fields

   The IPv6 base header fields are classified as follows:

   Immutable
             Version
             Payload Length
             Next Header (This should be the value for AH.)
             Source Address
             Destination Address (without Routing Extension Header)

   Mutable but predictable
             Destination Address (with Routing Extension Header)

   Mutable (zeroed prior to ICV calculation)
             Class
             Flow Label
             Hop Limit

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Charles E. Perkins
Sent: Friday, January 04, 2002 9:33 AM
To: Brian E Carpenter
Cc: Margaret Wasserman; [email-masked]
Subject: Re: Flow Label

Hello Brian,

Regards,
Charlie P.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 07 Jan 2002 11:14:57 +0100

We've already discussed the weak trust model aspect. Basically nobody will be
doing cryptographic authentication of the flow label at line speed, and if it isn't
done at line speed what's the point?

   Brian

---

From: "Subrata Goswami" <[email-masked]>
Date: Mon, 7 Jan 2002 09:06:17 -0800

The main point is, if I am a provider and I get a packet, how can
I be sure that some malicious entity in the middle has not modified
the flow label  so that it can avail of better QoS ? Second your
assumption of not being able to handle flow label authentication may be
too conservative in light of Moore's law and developments in optics.
Third, not everybody works at the speed of 10GigE or OC-192 - there
are networks that works at lower speed where it is entirely possible
to do header processing in silicon even now.  Fourth, you would still
need to change a Proposed Standard - so while we are at it why not
make it more complete.

Also unless there is a mechanism to verify the immutation of the
flow label, just saying it is immutable is akin to making a law
and having no way to enforce it.

So my  vote  ( I am not sure how much it is worth) would be
not to make it immutable unless we provide a way to verify the
immutation.

Subrata

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Brian E Carpenter
Sent: Monday, January 07, 2002 2:15 AM
To: Subrata Goswami
Cc: [email-masked]
Subject: Re: Flow Label

We've already discussed the weak trust model aspect. Basically nobody will
be
doing cryptographic authentication of the flow label at line speed, and if
it isn't
done at line speed what's the point?

   Brian

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 07 Jan 2002 09:40:29 -0800

Hello Subrata,

> not to make it immutable unless we provide a way to verify the

I think we ought to make it immutable now, and worry over
verification later.  Maybe it won't be very much later, but
the specification for immutability should not be made to
wait for it.

Regards,
Charlie P.

---

From: Alex Conta <[email-masked]>
Date: Mon, 07 Jan 2002 15:13:51 -0500

The facts you mentioned (checksum and AH calculation) are wellknown, but
a clear reminder is certainly useful for those who forgot, or ignored
that.

One of the comments pro "immutability" was that you cannot trust the
flow label 
if it is not "immutable". But the no way to enforce or validate it --
possibly grotesque 
inconsistency -- is not why I am NOT for "immutability". 

The list of the flow setup and flow processing mechanisms is an open
list: we do not know today all possible ways in which the flow label
would be setup or used, in 10 or 20 years from now.  

Current or future flow setup and flow processing mechanisms, do now, or
will, in the future, 
KNOW BEST the micro-details of the flow label usage. Therefore
responsibility of the immutability/mutability of the flow label value
should stay ALONE with those mechanisms.

By leaving mutability alone, possible issues with checksum, and AH
calculation can be really forgotten, or ignored.

Alex

---

From: Robert Elz <[email-masked]>
Date: Wed, 09 Jan 2002 10:08:28 +0700

Date:        Mon, 07 Jan 2002 15:13:51 -0500
    From:        Alex Conta <[email-masked]>
    Message-ID:  <[email-masked]>

  | One of the comments pro "immutability" was that you cannot trust the
  | flow label if it is not "immutable".

I didn't ever see that argument.   What I saw was that you can't rely upon
it if it isn't - but not from the point of view of the recipient, from the
point of view of the sender.   That is, if the value might be changed to
any random thing, what's the point of setting it all, ever?  It would just
be meaningless bits (imagine a router forwarding a packet through an
encrypting tunnel, and seeing some mutable bits - ones it is allowed to
alter - and filling them with a random value in order to make cryptanalysis
more difficult).

  | Current or future flow setup and flow processing mechanisms, do now, or
  | will, in the future, 
  | KNOW BEST the micro-details of the flow label usage. Therefore
  | responsibility of the immutability/mutability of the flow label value
  | should stay ALONE with those mechanisms.

I think in this case, you really favour making the field immutable, but
unverified.   If it were truly mutable, it would never be able to be used
for any of those uses, as no-one could ever rely upon any value they set
remaining intact to the point where it was supposed to be used (the "router"
in my previous paragraph might be a link level bridge type object - even
imagine a NIC that sees this mutable field and uses it to send to the
destination a count of the number of times it deferred because of a busy
link before sending the packet...)

If some future spec wants to make the field mutable, then as long as we
have not done anything silly (like modify the current AH rules) to prevent
it, then that spec will be able to do that - and with a good chance of
being able to rely upon the value only being changed as the future new spec
actually says should happen.

  | By leaving mutability alone, possible issues with checksum, and AH
  | calculation can be really forgotten, or ignored.

This amounts to "make it immutable, don't change AH, and explain in the
doc that AH explicitly doesn't include the flow label, to leave open the
possibility that some later spec might specify conditions under which the
field can be changed".   Until this later spec appears though, I don't think
we need to anticipate its requirements, and waste time here debating
whether or not those unknown future requirements are a good thing or a
bad thing.

All we need to do now is avoid doing something truly silly like revising
AH to have it include the flow label.

The only plausible "mutable" argument I can see remaining for now is to have
a case where the source host says "I don't care what is in this field, I
am not setting it to anything".   I haven't yet even seen an argument as
to why that value has to be immutable (by definition it has no meaning to
anyone).   So, I'm still in favour of allowing that.   But not so much as to
object to a doc that doesn't include it - after all, no-one will ever care if
that value is changed, so if anyone wants to do so, they can, regardless of
what this new spec on the flow label claims.

kre

---

From: "Dr. Subrata Goswami" <[email-masked]>
Date: Tue, 8 Jan 2002 21:28:11 -0800

Here we go again, I guess first we need to make sure
what immutability really is. The proper semantic of
something immutable is that it can not be changed -
as when you ship a CD that is only readable. With an IPv6
packet that is not possible unless every router vendor
and IP stack vendor is some how forced to do that. Even
the IP address fields are mutable as any intervening router
can change (and they do in case of NAT). So the only way
to enforce immutability is to add something like the AH so
that anyone who is concerned with the Flow Label can be
sure that no router in the middle has tempered it.

Subrata

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Robert Elz
Sent: Tuesday, January 08, 2002 7:08 PM
To: Alex Conta
Cc: Subrata Goswami; Brian E Carpenter; [email-masked]
Subject: Re: Flow Label

object to a doc that doesn't include it - after all, no-one will ever care
if

kre

---

From: Robert Elz <[email-masked]>
Date: Wed, 09 Jan 2002 13:45:04 +0700

Date:        Tue, 8 Jan 2002 21:28:11 -0800
    From:        "Dr. Subrata Goswami" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Here we go again, I guess first we need to make sure
  | what immutability really is. The proper semantic of
  | something immutable is that it can not be changed -
  | as when you ship a CD that is only readable.

Yes, though we perhaps aren't using it in quite that sense, more
in the "must not be changed" rather than "can not be changed".

  | With an IPv6
  | packet that is not possible unless every router vendor
  | and IP stack vendor is some how forced to do that.

But that's certainly not true.   We don't have to force them, we just
need to tell them what is right.   That's all the IETF ever really does.

  | Even the IP address fields are mutable as any intervening router
  | can change (and they do in case of NAT).

Yes, exactly.   Yes and (NAT set aside for a minute) the IP address fields
have just the properties that we are really aiming for here.   That is,
they aren't changed by random routers along the path - packets get delivered
with the same addresses in them that they had when they left the source
(or did, pre NAT).  And that was achieved without AH existing yet to
validate things - the routers simply didn't alter the fields.

That's what is desirable here.

But then, along came the need for NAT (as evil as it is, there must be
a pretty strong case for it, given its widespread use).   Implementing that
meant that the address field, which previously had never been altered,
now needed to be changed by routers.   Had there been any enforcement of
the immutability of the addresses, then there would have been no way to
add NAT to the net (which might have been good, or bad, but for sure the
net now would be nothing like it is if not for it).

  | So the only way
  | to enforce immutability is to add something like the AH so
  | that anyone who is concerned with the Flow Label can be
  | sure that no router in the middle has tempered it.

If there was any reason to enforce it, that would be correct.  But there
isn't - so we don't need this.

And if we did, then there'd be no possibility later to come up with some
new use which requires the field to be mutable (and argue about it a lot
in the IETF and perhaps eventually agree to it).   At this stage in the
evolution of the flow label, completely cutting off that possibility is
unreasonable.

In practice, if actual immutability is required by applications that use the
flow label, then what will "enforce" the immutability is the screams of the
users at the router vendors/operators if they start playing about with the
data.   Just as would happen if (aside from the explicitly configured NAT,
and even that generates plenty of screaming) routers started randomly
changing IP addresses.

If there's never an application actually deployed that cares, then why would
anyone else?  In that case, if someone decides to alter the field, no-one
would notice - and there's no reason to go and add a mechanism just to detect
something that no-one cares about anyway.

kre

---

From: "Dr. Subrata Goswami" <[email-masked]>
Date: Tue, 8 Jan 2002 23:12:05 -0800

Well I would not recommend settling something with screams.
Making the Flow Label immutable would infact need more than
screams.

I can not see how by just saying something is immutable going
to help. It would infact be the ground for more confusion,
uncertainty, doubt and vendor specific interpretations. I would
also recommend adopting the semantics of immutability from the
AH RFC 2402  - I guess that is where the word immutable first
appears.

Also, as you know AH is completely broken by NAT.  Why has
NAT become popular ? I can only guess: a quick and dirty fix
for IPv4 address scarcity; some firewall benefits.

The

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Robert Elz
Sent: Tuesday, January 08, 2002 10:45 PM
To: Dr. Subrata Goswami
Cc: [email-masked]
Subject: Re: Flow Label

  | With an IPv6

  | So the only way

If there's never an application actually deployed that cares, then why would
anyone else?  In that case, if someone decides to alter the field, no-one
would notice - and there's no reason to go and add a mechanism just to
detect
something that no-one cares about anyway.

kre

---

From: "Jim Fleming" <[email-masked]>
Date: Wed, 9 Jan 2002 09:22:54 -0800

----- Original Message -----
From: "Robert Elz" <[email-masked]>
To: "Dr. Subrata Goswami" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, January 08, 2002 10:45 PM
Subject: Re: Flow Label
...
> data.

"tell them what is right" ????

NAT is a bogus example, because addresses are not changed by the
carriers (ISPs?) that take in native IPv4 packets on one side of the legacy
IPv4 cloud and produce the same packets on the other side of the cloud,
based on the address. A person with a PC--NAT configuration, has just
buult a super PC with their stack remoted to the NAT appliance. With two
PCs and Internet Connection Sharing (ICS), the trio of machines still appear
as one aggregate to the legacy IPv4 transport. More of the bits in the IPv4
header can be used, because the NAT appliance can be upgraded easier
than their PCs. There are only 20 bytes in the typical IPv4 header and most
users do not use them all effectively.

The TOS field is a much better example to use, with respect to changing
bits that the user does not want changed. The TOS field is 8 bits, and what
goes in should come out. Why does the IETF, (described by the ICANN
Board, as their "Engineering Division"), think it can come in after the fact
and start having carriers change the bits in the user's TOS field ? Is the
reason that the IETF does not want users to discover that those 8-bits can
be used as two 4-bit fields to expand the addressing of the Internet by
adding
15 more layers, flows, etc. ??? Why is it that the IETF's attempts to
encourage
carriers to change the TOS fields, removing them from the user's usage, are
viewed as OK, while NAT is the poster child for all things bad ? Why is it
that the IETF (and ICANN) are able to be so selective (and inaccurate) in
choosing what they view as breaking the net ?...yet, run around claiming
that
they know what is right....

Do you use a 2002 prefix ?
http://www.dot-biz.com/INFO/Papers/

Jim Fleming
2002:[IPv4]:000X:03DB
http://www.IPv8.info

---

From: "Jim Fleming" <[email-masked]>
Date: Wed, 9 Jan 2002 09:36:54 -0800

----- Original Message ----- 
> for IPv4 address scarcity; some firewall benefits.

NAT has become popular, partly because of the absurd, subjective,
IPv4 allocation policies, enacted by the academics and government
employees (who usually pay nothing for allocations), and backed by
the large corporations who have their own massive allocations separate
from the rest of the peasants.

NAT has also become popular because of a natural tendancy for humans
to simplify via aggregation and encapsulation. Look at everyday life, much
of what goes on is people putting things into other things and labeling the
result.

You might try working the other direction to see why NAT makes sense.
Take a typical PC. Look at the physical components, CPU, Keyboard,
Mouse, Monitor, Printer. Imagine that all of those components were on
a high-speed LAN as their interconnect. Imagine that each of the components
had a unique IP address. Would people find it useful to ping the mouse of
someone on the other side of planet Earth ? No, they box it all up and call
it a PC, and give it one IP address, they then box their PC up with a NAT
appliance and call that a vPC (Virtual PC). They then move in the other
direction with a focus on the "services" that their vPC can provide and
access. It is a natural evolution.

The control freaks of course do not like people having knowledge and
the ability to do their own packaging and administration. They have built
their careers making resources scarce and telling people what is "right".

Jim Fleming
2002:[IPv4]:000X:03DB
http://www.IPv8.info

---

From: "Jim Fleming" <[email-masked]>
Date: Wed, 9 Jan 2002 10:33:07 -0800

----- Original Message ----- 
> to help. It would infact be the ground for more confusion,

If users use a field and expect it not to change, then carriers (ISPs?)
have to take note of that. In IPv6++, every bit in the 40 byte header
is used. The 20 bits that were not defined, have a 4-bit length field
and a 16-bit value. There are also 16 other bytes for data. Small
packets, such as the common ping, fit totally in the header. Add an
IPv4 Routing Header in the front (where it belongs), and use all of
the bits in that 20 byte data structure and call it a day. Why would
carriers change those 60 bytes ?

Jim Fleming
Unir Corporation - UNIR and COM worlds @ http://www.activeworlds.com
vPC + C+@ + IPv8 + 2,048 TLDs...this network solution is simple...
http://www.ddj.com/articles/index/author/idx10133.htm

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Jan 2002 15:09:10 +0100

Subrata Goswami wrote:
> the flow label  so that it can avail of better QoS ? 

You can't, any more than you can be sure the DSCP hasn't changed, or that
somebody isn't playing games with port numbers to fool your classifier.

The ISP's defence against this is that more QoS will result in a higher bill.
So the ISP actually doesn't care; they get paid accordingly.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Jan 2002 15:16:30 +0100

kre is correct IMHO, and we won't get any further by repeating
this loop again.

However there is one qualification on kre's final comment:
> ...if someone decides to alter the field, no-one

The field could theoretically be abused as a signalling channel by malicious
people - detecting this might be of value in some circumstances. 

  Brian