These are four interesting words: restores uncertainty preventing usage
Restores implies that something used to be some way and it is now restored to be that way. That is not the case with technology very few people use. As for uncertainty, there does not seem to be any uncertainty when one looks at working code. Fortunately, people writing code and compiling their own operating systems are not prevented from using any data structure the way they want. When a large number of people start doing things in a similar manner a standard emerges. It seems unlikely that people could decide in advance what the standards will be and impose those on the population. Regarding the 20-bit Flow Label, in the bloated 40 byte IPv6 Header, one approach may be to divide the Flow Label into a 4-bit Length Field, an 8-bit StarGate and an 8-bit Identification Field similar to IPv4. The 4-bit Length Field can then be used to define the number of bytes of data carried in the useless, right-most, 64-bits of the IPv6 128-bit Address Fields. Those fields used to have MAC addresses but now some claim they have random numbers. The Protocol Field could of course further define the one to sixteen bytes of data carried directly in the IPv6 header. While 16 bytes be small for protocols involving huge files, streaming protocols and other object-oriented applications may find that 16 bytes is a nice size, and they could use the IPv6 header more efficiently. Jim Fleming 2002:[IPv4]:000X:03DB http://www.IPv8.info ----- Original Message ----- From: "Brian E Carpenter" <[EMAIL PROTECTED]> To: "Alex Conta" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, January 02, 2002 4:29 AM Subject: Re: Proposed update to RFC 2460 [was Re: Flow Label] > Alex, > > I don't agree. This restores the uncertainty that is preventing any > current usage. > > Brian > > Alex Conta wrote: > > > > Making the field "immutable" by "default", but "mutable" when a router > > is so instructed by a flow setup and flow processing mechanism is a > > compromise that would satisfy all current and future possible cases. > > > > Therefore I think last sentence of the first paragraph > > > > All routers MUST pass the field on unchanged when forwarding a > > packet. > > > > should be something like: > > > > All routers MUST leave the field unchanged, by default, when > > forwarding a packet. > > A specific flow setup/processing mechanism MAY give a "mutable" > > character to the field, > > by requesting routers, supporting the mechanism, to change the field > > in certain ways. > > Routers supporting such a mechanism MUST follow the steps indicated > > by the flow > > setup and flow processing mechanism. > > > > Alex > > > > Brian E Carpenter wrote: > > > > > > Taking Scott's suggestion, here's another try: > > > > > > I'd like to propose the following as the > > > complete and total replacement of Section 6 of RFC 2460. > > > > > > The 20-bit Flow Label field in the IPv6 header MAY be set by a > > > source to uniquely 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 delete Appendix A, which is unhelpful.] > > > > > > Brian > > > -------------------------------------------------------------------- > > > 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] > > > -------------------------------------------------------------------- > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Distinguished Engineer, Internet Standards & Technology, IBM > On assignment at the IBM Zurich Laboratory, Switzerland > Board Chairman, Internet Society http://www.isoc.org > > > -------------------------------------------------------------------- > 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] --------------------------------------------------------------------
