Re: End-to-end (was Re: Non-Last Small IPv6 Fragments)

[Brian E Carpenter <[e-mail]>]

Hi,

A small comment at the end...

On 2019-01-17 06:28, Tom Herbert wrote:
> On Wed, Jan 16, 2019 at 8:36 AM Fernando Gont <[e-mail]> wrote:
>>
>> On 16/1/19 12:41, Tom Herbert wrote:
>>> On Tue, Jan 15, 2019 at 11:52 PM Fernando Gont <[e-mail]> wrote:
>>>>
>>>> On 15/1/19 19:42, Tom Herbert wrote:
>>>> [....]
>>>>> packets. This uses a modifiable HBH options and is completely
>>>>> idependent of the transport layer.
>>>>
>>>> You cannot use HBH in the public Internet. Well, you can... but there
>>>> high chances your packets will be dropped.
>>>>
>>> Fernando,
>>>
>>> By that same thinking we can't use any extension headers at all,
>>
>> Indeed.
>>
>>
>>
>>> any
>>> transport protocol other then TCP (and maybe UDP), ICMP, the TCP
>>> authentication option, TCP fast open, UDP options, or even IPv6 on the
>>> Internet.
>>
>> I assume that such options focus on specific scenarios (e.g. TCP-AO for
>> BGP), or they have fall-back options (e.g. traditional open for TCP-FO).
>> Otherwise they are doomed to fail.
>>
>>
>>
>>> As for HBH, RFC8200 relaxed the requirement that intermediate nodes
>>> need to process them. If a node just wants to get to the transport
>>> layer it can skip over the EH very with a few simple operations. I see
>>> no excuse for new devices being deployed to systematically drop HBH or
>>> destination options EHs. If they are  doing that then their
>>> implementation does not comply with the IPv6 standard and we shouldn't
>>> have any compunction about publically calling them out on that.
>>
>> See https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops
>>
>> The folks running the networks have work to do. And will certainly not
>> pay extra money for functionality that somehow is currently not
>> required. Vendors will not invest extra to sell devices at the same price.
>>
> I'm not sure what you mean by "functionality that somehow is currently
> not required.". Who determines what is required?
> 
>> We can call them out. Vendors for selling boxes that perform very badly
>> for packets that contain EHs, and operators for "looking into packets in
>> the middle of the network, breaking the sacred e2e principle (or some
>> interpretation of it)".
>>
>> Then I guess *we* will be called out to pretend doing engineering, while
>> doing stuff that doesn't work in practice.
>>
> There is engineering happening. The requirement that every node needs
> to process HBH options where there could be hundreds of options in a
> single packet was, in retrospect, completely impractical to expect to
> be supported. So, RFC8200 relaxed the nodes must process requirement,
> and we can define some reasonable limits as to how many options can be
> processed. These are examples of updating standards that make
> engineering feasible.
> 
>> We burying our heads into sand doesn't help the situation, either...
>>
> 
> Agreed. If someone were to *prove* conclusively that it is impossible
> to support even the minimum requirement that allows device to skip
> over HBH options, then I would agree that it may make sense to give up
> and deprecate them. But until we have that proof in hand, the problem
> is real and needs to be dealt with.

My conclusion about what we should do is a bit different, and is
expressed in draft-carpenter-limited-domains (preferred list for
discussion is [e-mail]).

   Brian

    Brian