RE: ingress filteing problem

["Christian Huitema" <huitema@windows.microsoft.com>]

> > > What you describe here is "rewrite at both ends", which supposes
that
> > > both ends are somehow upgraded. My contention is that the solution
to
> > > ingress filtering should be "single site", i.e., not force any
special
> > > processing on the other end, which may well be running a
non-updated
> > > IPv6 network.
> >
> > Yes, additionally, a solutions that supports "old" IPv6 hosts (i.e.
> without
> > any specific multihoming support) within the multihomed site would
be
> > preffered, i guess, since it doesn't impose a flag day in the
multihomed
> > site when all the internal hosts have to be upgraded.
> >
> > So backward compatibility on external hosts (and sites) and also in
> internal
> > hosts
> 
> Of course I agree that the solution should not make things *worse*
> than today for non-multihoming-aware sites. But the ingress filtering
> problem that Christian describes surely exists today on such sites,
> which have no mechanism for choosing the appropriate exit router.

The current solution, in IPv4, is to allocate a single prefix to the
site and to have this prefix announced in BGP by all providers. The
solution does meet ingress filtering requirements, and does not impose
any constraint to internal hosts or external peers. We can indeed
replicate that for IPv6, but I was under the impression that we would
rather do without routing table explosion.

-- Christian Huitema