Hi Andrew, I fully understand your perspective. I am just questioning if ethertype is the right level to introduce a fail-closed solution.
As you know IETF is very creative in inventing more and more services running over IP. Lot's of them would benefit perhaps from such fasil-closed automation. But adding new ethertype for each is no go IMHO. With that IPv6 addresses are big enough so for example embedding well known few bits in src IPv6 address could easily automate and apply protection for lot's of current and future services running on IPv6. And if not mangling with IPv6 addressing architecture then extension header could be defined there completely independent from service headers to be used for such protection. Main point being that while we are going to go via pain of network upgrades I would rather recommend to do it in a much more universal way. Cheers, Robert On Tue, Mar 28, 2023 at 6:47 PM Andrew Alston - IETF <andrew-i...@liquid.tech> wrote: > Hi Robert, > > > > The way the authors view this – and what we will be adding possibly more > explicitly in the document, is that this does not force an ethertype onto > srv6 – it creates an OPTION for operators that want to run it in this mode > to do so. It introduces a choice that following consultation, many > operators seem to want. > > > > In our view – this is in the interests of the both the operators and the > vendors – the operators who feel more comfortable with a fail-closed > solution, and the vendors because the goal here is to get the operators > happy enough to actually deploy the technology. Yes, there is some srv6 > deployment, but it is nowhere near ubiquitous – and for a number of > operators – the lack of fail closed mechanism is preventing them from > deploying. > > > > I would ask that you look at this in that light – we do not wish to stop > anyone running srv6 in the standard mode, we wish to provide an option that > does not interfere with existing srv6 to those that may want to use the > technology, but aren’t comfortable using it in the absence of this > mechanism. > > > > Thanks > > > > Andrew > > > > > > *From: *Robert Raszuk <rob...@raszuk.net> > *Date: *Wednesday, 29 March 2023 at 10:30 > *To: *Andrew Alston - IETF <andrew-i...@liquid.tech> > *Cc: *adr...@olddog.co.uk <adr...@olddog.co.uk>, int-a...@ietf.org < > int-a...@ietf.org>, spring@ietf.org <spring@ietf.org> > *Subject: *Re: [spring] [Int-area] FW: New Version Notification for > draft-raviolli-intarea-trusted-domain-srv6-00.txt > > Andrew, > > > > To me the fact that SRv6 is using IPv6 ethertype is a feature not a bug. > It allows seamless deployment in any IPv6 enabled network. > > > > Yes I personally suggested a new ethertype for SRv6 long time back, but > the issue was related to hurdles with IPv6 standards not related to any > "security" issues. > > > > IP packets go from and two depending on their src and dst addresses. So > network(s) which fail to properly automate filtering of external packets > targeted to their internal infrastructure should be decommissioned, not > packets ethertype should change to keep those alive just to prevent IP > packets from "escaping" a domain. > > > > Last but not least, sending SRv6 services over completely unaware Internet > underlay is very useful. Just think about mobile services as an example. > > > > So I wish you all the best with srv6-td. > > > > Kind regards, > > Robert > > Internal All Employees >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
