Subject: RE: ingress filteing problem

From: "Christian Huitema" <[email-masked]>
Date: Mon, 15 Mar 2004 08:45:55 -0800

> > > 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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Mar 2004 09:32:11 +0100

> 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