This would all be much simpler if the SRV6 community explicitly dropped the claim to be implementing standard IPv6.
Whether the IETF wants to standardise something at layer 3 that isn't IPv6 is a separate question. It is pretty obvious that if spring adopts this draft and if it comes to IETF last call, that question will have to be resolved then. From the present discussion, there is very little chance of consensus. Regards Brian Carpenter On 10-Oct-21 08:06, Robert Raszuk wrote: > >> The all zeroes have a meaning in IPv6 address space > > I am not trying to say that all predefined IPv6 innovations in the remaining > bits are bad. > > So if I need to use subnet anycast to any ASBR advertising one of said /10's > I will put zeros in the remaining bits. Clearly this will not be SRv6 packet. > SRv6 spec does not claim everything MUST be SRv6 from now on :) > > Likewise if I need to use some format of the lower bits to get expected behaviour I will do so. > > I guess someone may be concerned what if any of the bits between /4 or /10 to > /64 accidentally overlap with standards based reserved use cases ? Well for > one IPv6 stack should prevent one from accidentally using it. And again this > has nothing to do with SPRING. If anything SRv6 implementations use IPv6 > stacks hence such protection will be there anyway. > > Best, > R. > > > On Sat, Oct 9, 2021 at 8:42 PM Tony Przygienda <tonysi...@gmail.com > <mailto:tonysi...@gmail.com>> wrote: > > As a simple example to which I already know your answer as in the usual > "oh, that will never happen" is the subnet routers anycast address I think. The all zeroes have a meaning in IPv6 address space and intermediate nodes that don't know they are dealing with a chipmunk may try to do something with it, probably kill the chipmunk or maybe turn it into a fish if they are in the next to be invented "ocean limited domain" which your chipmunk should never enter. > > Or maybe we all should read RFC2526 and make sure THAT never happens in a > chipmunk packet or if it does do we intend to remap a possible combination > that can be mistaken for anycast to something else so chipmunk doesn't become > a fish? Or maybe there is already a SRv6 draft I missed that declares IPv6 > anycast a violation of the chipmunk limited domain. > > As a historical example I lived, this is all oh so clever as folks who > figured out IPv6 actually did not explicitly forbid to assign the same link > local on a box to all interfaces (as far my thinking goes, a significant > mistake) which caused all kind of collateral for a bit actually and even > today, good luck to get all the linux tools to deal properly with %eth2 > without coring (and even better luck trying that with funky interface naming > that linux is employing all over the place). > > my last email on the subject (and I reserve right to maybe be off here > and there a bit, I'm not too deep into v6 and SRv6 but I've seen enough > architectural and WG mistakes to see this compression draft red-zoning), > let's see what the WG moves fwd' with > > -- tony > > On Sat, Oct 9, 2021 at 8:14 PM Robert Raszuk <rob...@raszuk.net > <mailto:rob...@raszuk.net>> wrote: > > Tony, > > /(yes, you can hijack any address architecture if you _assume_ that > only /4 will be routing table entries & the rest belongs to your new interpretation of address being a chipmunk that by magic means will never ever escape a private basement until it does). > / > > Let's try again ... as it seems this keeps coming back over and over again. > > Assume I got allocated /4 from RIR and I have allocated /10 blocks to > my global sites connected over plain IPv6 Internet. I advertise those /10s > via BGP. > > What technical harm will happen to anyone if I use bits 11-128 as it > seems to fit and still send those packets via v6 Internet ? No basement, but public Internet. > > Last time I checked bits are bits and there is either 0 or 1 in the packets (at least till we get to quantum networking). It should be in no one's business in the transit to look anywhere beyond /10. > > Again please limit the answer to technical issues which this will > cause. > > Kind regards, > Robert > > > > > > > > > > On Sat, Oct 9, 2021 at 5:50 PM Tony Przygienda <tonysi...@gmail.com > <mailto:tonysi...@gmail.com>> wrote: > > I object adoption of this document as well based on copious amount of technical counter arguments laid out in multiple threads. Beside that it seems that to violate IETF v6 architecture documents we seem to be trampling on established standards more and more using increasingly contorted sophisms (yes, you can hijack any address architecture if you _assume_ that only /4 will be routing table entries & the rest belongs to your new interpretation of address being a chipmunk that by magic means will never ever escape a private basement until it does). > > Beside that as others already pointed out copiously the document > content does not even seem to actually match WG consensus as recorded to my > understanding > > --- tony > > On Fri, Oct 1, 2021 at 10:37 PM Ron Bonica > <rbonica=40juniper....@dmarc.ietf.org <mailto:40juniper....@dmarc.ietf.org>> > wrote: > > Folks,____ > > __ __ > > Draft-filsfilscheng-spring-srv6-srh-compression-02 introduces > three new SID types that can occupy the Destination Address field of an IPv6 > header. See Sections 4.1, 4.2, and 4.3 of the draft for details.____ > > __ __ > > The SPRING WG has issued a call for adoption for this > draft.____ > > __ __ > > It is not clear that these SID types can be harmonized with > the IPv6 addressing architecture.____ > > __ __ > > Does anyone have an opinion?____ > > __ __ > > > Ron____ > > __ __ > > > Juniper Business Use Only > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > i...@ietf.org <mailto:i...@ietf.org> > Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 > <https://www.ietf.org/mailman/listinfo/ipv6> > > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > i...@ietf.org <mailto:i...@ietf.org> > Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 > <https://www.ietf.org/mailman/listinfo/ipv6> > > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > i...@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
