Re: ingress filteing problem

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

Christian Huitema wrote:
> 
> > > > 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.

Indeed. What I was saying (badly) is that today, an IPv6 site which
has two prefixes and two ISPs has exactly this problem, even without
any multihoming mechanism defined. 

   Brian