There were several issues raised. I don't think fragmentation actually came up
as one of them, but that is good point.
Intermediate nodes cannot fragment packets in IPv6.
- The proposal attempted to carve out an exception to RFC8200 for just SR and
limited use to controlled domains. That entails many caveats an assumptions
that would need to be MUSTs.
- Encapsulation is recommended to allow EH insertion and several people asked
why not use it. It will work inasmuch as encapsulation within the network
- If a host is already using extension headers and the network tries to add
more, there is an ambiguity about which ones the.network is responsible for.
When packet leaves the domain, the EH that the network added needs to be
removed and it needs to be unambiguous which ones are to be removed.
- ICMP is a problem. If a host gets an ICMP error that contains extension
headers that it did not possibly send then that will be confused. Presumably,
ICMP errors will need to be stripped of EH before forwarding to a source node.
- PTB is interesting. For instance, EH insertion could force PMTU to drop below
- If the added extension headers are causing packet drops this is a major
problem. The intermediate node that is inserting the EHs will never get
feedback that its actions are doing harm. An end host might detect packet loss
at the transport layer or might get an ICMP error (maybe something like
But, even if it knows that inserted EHs are causing drops, there's is no
action a host can take to stop it. At least with encapsulation the tunnel
ingress might get and ICMP error about what it's doing.
I suppose the primary argument against encapsulation is that it's too much
overhead. But, I would point out that in the examples if only one sid is
required for mobility (address of destination) in an IP/IP encapsulation this
would be the destination of the inner packet and SRH wouldn't be needed.
[Uma]: SRH in the proposal not only put a sort of mobility solution (encoded in
the SID) but also use to guide the packet through non shortest path from the
source as needed and as listed in the SRH.
One of the assumption, I saw the discussion here, ILA and 5GIP
seems to assume delivering the packet to the shortest path but this may not be
necessary the case for lot of 5G slices and also tunneling in couple of cases
is unavoidable (if you ought to overlay IPSec in few cases).
So encapsulation overhead = 40 bytes, SRH overhead = 20 bytes. I'm not sure
that difference justifies the complexity of EH insertion.
[Uma]: If you include the above difference is not quite that. But re-encap
seems lot safer for some of the points you raised above.
dmm mailing list