Re: proposed text for header injection revision 05

[Mark Smith <[e-mail]>]

On 23 July 2016 at 09:40, Hemant Singh <[e-mail]> wrote:
> Sorry, my bad for including "intentional".   It's just ambiguous related to
> the term "processed" which is not clear and called out by many others as
> ambiguous.

I think the claim of ambiguity is dubious. Processing is what
computers do, and these devices are specialised computers. If the word
'processing' hasn't been clarified, then it means performing any
actions on the EHs.

I think this is what actually happened:

1. Some people thought the way to solve their problem was to insert
EHs into existing, in flight packets
2. They didn't consult RFC2460 to see if was acceptable to do that
3. They now want a loophole created in RFC2460bis to accommodate
behaviour that isn't permitted, claiming that RFC2460 is ambiguous.

I have two fundamental objections:

- I've dealt with devices that silently change packets or frames in
flight, intentionally or in error, and know how hard they can be to
troubleshoot. Packets that are not modified in flight in any way at
all would be the ideal, because if the packet that arrived wasn't the
packet sent, then something is broken in the network, and network
processing of packets would be no more than look at a value or values
in the packet fields and then perform the small set of actions
necessary to forwarding them.+

- i don't agree with trying to make non-compliant behaviour compliant
by creating a spec loophole using a claimed ambiguity, when an
understanding of the meaning of the words "examine" and "processed"
are fundamental to the field of computing and networking. The heart of
a computer is the Central Processing Unit!

I understand people have work they've put effort into that would be
non-compliant if this loophole isn't created. However, just because
the work exists doesn't mean it now has to be accommodated in the
specifications.

I think the discussion about what and what not to put in regarding
what inserting EHs breaks also shows that this area is not fully
understood or investigated. I think that is also another sign that the
consequences of inserting EHs into existing packets isn't known and
complete. It think it needs to be properly understood and documented,
and then if the benefits are worth the drawbacks, the specification
could be updated to permit it.


Regards,
Mark.

+ If you look at the early versions of IP (e.g., RFC675, various
IENs), for versions 1 through 3 (1974 through 1978) it seems the only
modification of packets that is permitted in the network is
fragmentation (which isn't really modification, rather it is
replacement of one packet with the creation of multiple new packets
carrying the original packet's data). There is no TTL field or hop
count field. I think that indicates that during that design period
there was an expectation that packets were not to be modified in
flight at all, which is the simplest thing to do - just look at them
and forward them, no modification required. TTL or Hop Count fields
are a reasonable safety measure, however they're per-packet overhead
and additional per-hop processing to mitigate what should be a short
lived and transient state of a loop. Ideally, if entirely loop free
routing protocols had been invented (which was probably the
expectation between 1974 and 1978), there'd be no need to have and pay
the price of TTL or Hop Count fields in each and every packet and the
cost of modifying them at each hop.



> Hemant
>
> On Fri, Jul 22, 2016 at 7:37 PM, Mark Smith <[e-mail]> wrote:
>>
>>
>> I haven't seen any evidence of international ambiguity. Brian found an
>> email from Steve Deering explicitly stating that if you want to add an EH to
>> a packet you add it via encapsulation within another IPv6 packet.
>>
>> The following is not ambiguous.
>>
>> "With one exception, extension headers are not examined or processed by
>> any node along a packet's delivery path, until the packet reaches the node
>> (or each of the set of nodes, in the case of multicast) identified in the
>> Destination Address field of the IPv6 header."
>>
>> For those claiming it is, you must explain to the rest of us how you
>> insert EHs with out "examining" or "processing" the existing EHs.
>>
>>
>