Re: [IPv6] Removing extension headers from packets (revisited)

[Mark Smith <[e-mail]>]

Hi Tom,

On Tue, 15 Aug 2023 at 14:50, Tom Herbert
<tom=[e-mail]> wrote:
>
>
>

<snip>

>
> I don't think there's any reliance on this being present. If packets don't have extension headers removed then they're leaked outside of the domain and are subject to higher drop rates.
>

I think this is assuming that the adjacent and upstream domains
(networks) will never be using the same EH for their own purposes.

If this EH is useful to you locally, then you can't prohibit your
adjacent or upstream domains from using it too just because you are.


> Encapsulation requires two parties to coordinate, the encapsulator and decapsulator. So in the models discussed, either the source host needs to encapsulate and edge router decapsulates, or edge router encapsulates and the final destination host decapsulates-- in either model hosts have to change and neither set of hosts are managed by a single entity (e.g. smart phones and web servers). Removing EH at the edge has the advantage of only have to change routers under the control of a single domain.
>

What if the EH isn't actually removed, because of:

- implementation bugs

- partial node failures that might fail to remove EHs yet still forward packets

- operator device misconfiguration

?

These and other problems caused by EH removal were covered in the
"In-Flight EH Insertion Considered Harmful draft in the section about
failed EH removal.

https://datatracker.ietf.org/doc/html/draft-smith-6man-in-flight-eh-insertion-harmful-02

I presented on it at IETF 106, slide deck:

https://datatracker.ietf.org/meeting/106/materials/slides-106-6man-sessb-in-flight-ipv6-extension-header-insertion-considered-harmful-00

It was suggested that it be worked towards publishing as a 6man WG
RFC, however quite frankly, I could tell it was going to be ignored by
the SPRING working group, and it was, so I didn't bother spending any
further time on it.


Regards,
Mark.



> Tom
>
>
>> Yours,
>>
>> Joel
>>
>> On 8/14/2023 10:52 PM, Tom Herbert wrote:
>>
>>
>>
>> On Mon, Aug 14, 2023, 6:12 PM Joel Halpern <[e-mail]> wrote:
>>>
>>> Yes, knowing what the correct egress should be is, for the general case, a harder problem.  But, the example you cited is segment routing.  If the host is trusted enough by the operator to actually provide a segment route across the operator domain, it seems necessary for the host to have enough information to properly address the egress.  Thus, for the case you chose for an example, encaps seems quite natural, efficient, and achievable.
>>
>>
>> Okay, maybe segment routing wasn't the best example :-) Consider draft-kaippallimalil-tsvwg-media- hdr-wireless. The basic idea of this draft is to let hosts annotate packets with information, signals that can be consumed by the network to provide QoS. This is for 3GPP networks, so the hosts are potentially all the mobile devices in a network. The signals are only processed by one intermediate device in the path which is the Mobile Router (basically the first hop router). After that point, the signal is no longer processed. All the mobile hosts have is a default route to their carrier and a destination address, they don't have any knowledge of whether a packet will leave a limited domain and what the egress point-- and, in fact, we don't want them to have that information since it would expose information about the internals of the provider network.
>>>
>>>
>>> There may be other cases where knowing the proper egress is harder, but it seems to me that solving the information problem is MUCH easier than solving the problem of removing bytes from the middle of a packet at wire rate at a high speed inter-operator
>>
>>
>> Functionally, it's equivalent to a decap/encap operation, or a push/pop of headers. Maybe fixed function hardware can't easily do this, but I'd be surprised if programmable devices like P4 couldn't do it. Also, like in the case of draft-kaippallimalil-tsvwg-media- hdr-wireless, the last intermediate that processes thh HBH options could also be the one that removes it from the packet.
>>
>> In any case, the points about debuggability and feasibility are well taken, but those are operational concerns. I am still wondering if removing a HBH extension header could actually break the IPv6 protocol.
>>
>> Tom
>>
>>
>>> interface.
>>>
>>> Yours,
>>>
>>> Joel
>>>
>>> On 8/14/2023 9:05 PM, Tom Herbert wrote:
>>>
>>>
>>>
>>> On Mon, Aug 14, 2023, 5:53 PM Joel Halpern <[e-mail]> wrote:
>>>>
>>>> Hmmm.  Trimmed to focus on a point you make.
>>>>
>>>> Comments below.
>>>>
>>>> Joel
>>>>
>>>> On 8/14/2023 8:45 PM, Tom Herbert wrote:
>>>> >
>>>> > Hi Mark,
>>>> >
>>>> > No, it's not about bandwidth. It's about survivability and
>>>> > deployability of extension headers. The current prevailing belief is
>>>> > that extension headers are not usable across the Internet since there
>>>> > is a high probability of packet drop. However, within a limited
>>>> > domain, extension headers are deployable, especially if the network
>>>> > itself is consuming them as would be the case of HBH options
>>>> > requesting QoS or segment routing headers.
>>>> >
>>>> > This presents two problems:
>>>> >
>>>> > 1) Hosts create extension headers and if extension headers are known
>>>> > to work in a limited domain then they can safely use them _if_ the
>>>> > destination is in the same domain as the source and the entire path is
>>>> > within the same limited domain. The problem is that a host wouldn't
>>>> > necessarily know which destination are in the limited domain and which
>>>> > aren't
>>>> > 2) Even if a host knows it is sending to a destination outside of the
>>>> > limited domain, it might still want to apply the packets and services
>>>> > in extension headers for the time that the packet is in the limited
>>>> > domain. For instance, segment routing might be used to route a packet
>>>> > to a specific egress node. At the egress node, the SRH is removed and
>>>> > the packet can be forwarded into the Internet (I believe this was the
>>>> > scenario that motivated removal of SRH when it was presented a while
>>>> > back)
>>>> >
>>>> > The alternative for #2 that is usually suggested is to use tunneling
>>>> > from the source to an egress, for instance the outside IP header could
>>>> > contain the extension headers and the encapsulated packet is the one
>>>> > sent one the Internet with no extensions. That might work and be
>>>> > conformant, but it's significantly more complex and probably not as
>>>> > practical as just removing extension headers at the border router
>>>> > (more decisions, we have to explicitly route to egress points, more on
>>>> > the wire overhead, tracing ICMP errors back to a connection is
>>>> > tricky). Also, troubleshooting still can be difficult because the same
>>>> > packet looks very different depending on where it's viewed (for
>>>> > instance, at one point the packet is encapsulated, at another point
>>>> > it's not).
>>>> >
>>>> > Tom
>>>> > ---------------------------------------------------
>>>>
>>>> <jmh>   You state that encaps / decaps is "significantly more complex
>>>> and probably not as practical as just removing the extension headers at
>>>> the border rotuer."  I am missing something .  As far as I can tell,
>>>> decapsulation at an addressed egress is easy to implement and widely
>>>> supported in existing hardware. Removing a set of bytes from the middle
>>>> of a packet is not widely implemented, hard to do in fast path hardware,
>>>> and prone to interesting failures all its own.   I would have exactly
>>>> reversed the comparison you make. </jmh>
>>>
>>>
>>> Joel,
>>>
>>> Easy at the decapsulation, not necessarily at the encap point. It's the same problem I mentioned before, hosts wouldn't know when a packet will be leaving the domain, and even if they did they wouldn't easily know what the endpoint address of the tunnel is should be for the real destination.
>>>
>>> Tom
>>>
>>>
>>>
>>>
>>>>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------