>As Brian already rightfully said, perhaps not with the same words, the
>draft promotes the flow label format in the main text, which is the IANA
>based value format. As Brian, I believe more in the IANA format. The
>flow label formats in the Appendix are presented as possible choices,
>each with its advantages and disadvantages, and as a record of such
>choices. The draft states that in the Appendix.
then why you pushed those non-IANA values in the presentation?
this is the source of confusion.
>> I guess you are too optimistic. if you are using align-picky
>> architecture CPU for your router, I can panic your router by putting
>> some value that is not align-friendly into flow label field as the
>> extension header length.
>Memory alignment became an access speed issue with certain 64bit
>processor/memory architectures, because of the access in 32 or 64bit
>"blocks", aligned at 32, or 64bit boundaries, thus possibly requiring
>for a byte access, depending the position of the byte in the "block", a
>shift of 8, 16, 24, or more bits. But this is far from anything you
>describe.
>
>I am afraid "memory alignment violation" is more a result of one's
>imagination than reality.
you are horribly wrong. have you ever used alignment-picky CPUs
like alpha?
>> it is very different from IPv4 case. in IPv4 case, IHL field is the
>> one and only field trustable, and there was no ambiguity. for IPv6
>> extension header length, the actual value is detected only by chasing
>> header chain. your addition (of extension header length into flow
>> label field) is a non-trustworthy copy of the real value. if your
>> router believes that the value in flow label field, your router will
>> get tricked.
>Ultimately, as Brian pointed out, the Network Provider will charge the
>customer. The customer, if he/she is the culprit will pay, otherwise,
>will pay, and chase the culprit.
>
>For the sake of accuracy, for a flow label format that contains the
>length and the host-to-host protocol id, the flow label value should be
>set by the IPv6 stack, that is, the KERNEL. The user should only trigger
>the use of the label, but the two values - length, protocol id - would
>be set by the KERNEL, on "IPv6 output" code path. Both values are known
>on packet transmission. The length can be calculated and cached or
>stored in a field in the Protocol Control Block, or whatever structure
>is representing the communication.
how can you trust IPv6 stack that is in the possession of end user?
they can be hacked up. the only devices you can trust is those you
administer in your diffserv cloud. you can never trust customers
devices.
>> >As said above, the security risk is not higher than with the
>> >pseudo-random number.
>> I don't believe so.
>you are making it sound like there is NO RISK with the pseudo-random
>number, and that is NOT TRUE.
>Once a pseudo-random flow label has been generated and cached, the risk
>of high-jacking it, is NOT DIFFERENT than with the non-pseudo-random
>flow label value.
I believe there's substantial difference, but okay, I got your point.
itojun
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
