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 PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Charles E. Perkins
Sent: Friday, January 04, 2002 9:33 AM
To: Brian E Carpenter
Cc: Margaret Wasserman; [EMAIL PROTECTED]
Subject: Re: Flow Label
Hello Brian,
Brian E Carpenter wrote:
>
> 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
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.
> b) that the 3rd MUST should be SHOULD, i.e. immutability should
> 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.
>
> Brian
>
> Margaret Wasserman wrote:
> >
> > 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
> >
> > At 02:01 PM 1/3/02 , [EMAIL PROTECTED] wrote:
> > >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 PROTECTED]
> --------------------------------------------------------------------
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
