Hi Toerless I believe that IPv6 multicast comes in on its own MAC address so the multicast engine run rather than the unicast address.
In any case if the parser got an IPv6 packet, it would know from the DA that it was multicast. So I think you actually have a new packet, but with the same packet layout for both m/c and u/c. I am still struggling to see what a compatible packet looks like, thought I did not a couple of ideas in my other reply. - Stewart > On 2 Mar 2021, at 14:42, Toerless Eckert <[email protected]> wrote: > > Thanks, Stewart, inline.. > > On Tue, Mar 02, 2021 at 01:53:12PM +0000, Stewart Bryant wrote: >> I don???t think there is a simple backwards compatible approach, but we can >> probably do more than we do today. >> >> Backwards compatible means that you could put your new packet into a IPv6 >> parser and it would correctly forward the packet as if nothing had changed. > > Lets say for the sake of argument, IPv6 multicast routing would have been > added after IPv6 (unicast) > was first specified, as it actually was in IPv4 (but nobody wants to hear > IPv4 stories now *sob* ;-). > > Adding IPv6 multicast would then also not have been a backward compatible > extension in your definition. As would likely be any interesting new semantic > to be added - whether > or not that semantic requires packet header changes or not. So i think your > definition of > backward compatible is too constraining: > > In my definition, IPv6 multicast was backward at the system level because it > allowed/allows IPv6 > unicast to continue to exist and evolve as if IPv6 multicast didn't exist. > With the only > limitation that some address planning was/is needed to be able to carve out > unused address > space for new semantics. > > With this definition of backward compatibility i can equally introduce in a > backward > compatible fashion new addresses longer or shorter than 128 bit through > arbitrary packet > header enhancemeents, because all i need is to observe that the format on the > wire of > consenting subnet adjacent routers is nobodies business but theirs - as long > as they > manage to stay backward compatible in my definition. And when we utilize > additional > packet header fields or different addrss lengths, we would not even have to > carve > out more from existing IPv6 address space like we logically had to do for IP > multicast > and avoid further overloading of this address space (as Tony i think observed > to be a problem). > > That all being said: Of course, we can and should try to promote more > fundamental > enhancements to the definition of forwarding machineries to allow future > extensions > of semantics to be possible in-line with your definition of backward > compatibility, but > that i think a lot more ambitious. > > Cheers > Torless > >> You could I suppose put a well known IPv6 address in the IPv6 header and put >> the real address in an extension header, perhaps including the pointer to >> the address in the suffix of the IPv6 address to make finding the EH much >> faster, but I am not sure that is backwards compatible. >> >> I suppose it might be able to do a bit better if the address in the IPv6 DA >> was the DA of the egress router and old routers did best effort to the >> egress and newer routers knew to take a look at the extension header for >> more detail. >> >> I think that it is worth thinking about how we could do better than we do >> today, but I think we need to be careful with the term backwards compatible. >> >> - Stewart >> >> >> >> > > -- > --- > [email protected] _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
