There were several issues raised. I don't think fragmentation actually came up 
as one of them, but that is good point.
[Uma]:  Yes.
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 
already works.

- If a host is already using extension headers and the network tries to add 
more, there is an ambiguity about which ones 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 
576 minimum.

- 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.

Uma C.
dmm mailing list

Reply via email to