Hi Andrew, As just a little contributor to the spec let me provide my own personal view point.
Please kindly see inline ... > 1. What effect will this have on flow analysis if a packet is arriving > with a modified DA – that is going to subsequently change > > Flow analysis needs to recognize complete packet header (when ultimate packet DST resides) to calculate the truth about end to end flows. Sure it will take some time to build support around it, but this is nothing new. When you UDP ir GRE tunnel around some flows you have the same issue. See it took some time to perform decent flow analysis for MPLS packets. Frankly if I look at linux kernel even today there is no efficient support for hashing to multiple buffers from header above IP - so each time I need to get packet headers to my flow analysis software I need to add few lines and rebuild the kernel. Patch has been proposed long time back but it seems kernel maintainers do not understands the problem. > > 1. > 2. What effect will this have on inline systems that draw information > from both the SA and DA addresses (think DPI systems) > > Same answer as above. > 1. > 2. I have significant concerns that the utilization of an IPv6 address > in the manner described here could have under unintended and as of yet > unknown consequences. As an example, if filtering is done based on > destination address, does it not stand to reason that you create an attack > vector by allowing an extended next-hop header to programmatically change > that which is being filtered on, on the preceding hop. (Yes this is highly > theoretical, but – I’d like to hear the authors comments on this) > > It is trivial issue. You match on the DST in the SRH if different from your packet's outer header DST field. See in general network programmability is not an easy concept. It is almost like monolith linux kernal vs dynamically loadable modular one. There was huge resistance when this got introduced, but flexibility behind it won. Same for networking in general. See few years back Nick and his team rolled out OF. Well the mistake they did was the centralized approach and programming way too much to each network element. Proposed SRv6 NP is a new concept and likely it will take years to fully adopt and see blossom of its power - but even now at such early stage you can see islands benefiting from it already at some focused areas (5G rollouts). Yes I understand that as author of SRv6+ you want to save the legacy ASICs and keep the packet headers as small as possible - keeping programmability to the endpoints. Well if so I really see no reason why instead of this new SRv6+ proposal we eliminate overhead to zero yet allow flexible traffic steering with BGP Vector Routing as described here: https://tools.ietf.org/html/draft-patel-raszuk-bgp-vector-routing-07 Many thx, Robert
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
