Re: v6-in-v4 configured tunneling over v4 multicast (vs 6over4)

[Brian E Carpenter <brc@zurich.ibm.com>]

Maybe. But I was told by the people who implemented 6over4 a few
years ago that it was only one page of code anyway - so I am not
so sure about the simplification.

   Brian

Pekka Savola wrote:
> Hi,
>
> When discussing draft-savola-v6ops-tunneling-01.txt with Dave Thaler, 
> mainly about the necessity of 6over4 in the scenario where the IPv4 
> network is multicast-enabled but the v6 network is not, I came up with 
> an idea which I'm not sure if others have brought up in the past:
>
> If you want to create point-to-multipoint tunnels over v4 multicast
> infrastructure, wouldn't the obvious solution be simply using
> configured tunneling?  That is, you configure the tunnel destination
> v4 address to be a multicast address (this requires zero code
> changes), and the decapsulators configure their "local end" to be the
> multicast address (requires code change in the tunnel setup tool to
> permanently join the specified multicast address)?
>
> This would seem to act like a "statically mapped", simplified
> alternative to 6over4 which would only require an
> implementation-specific addition to join the multicast group.
>
> This is in line with RFC2893 and draft-ietf-v6ops-mech-v2-02.txt, as 
> long as you interpret section 3.6 loosely enough:
>
>    When an IPv6/IPv4 host or a router receives an IPv4 datagram that is
>    addressed to one of its own IPv4 addresses, [...]
>
> (this wording could be tuned, obviously.)
>
> Thoughts?