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> 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> > 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> 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 >>> Administrative Requests: 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
