Subject: RE: ingress filteing problem

From: "Christian Huitema" <[email-masked]>
Date: Tue, 16 Mar 2004 09:08:32 -0800

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

Agreed. For this reason, I believe that there are two tasks ahead of us.
The first one is to solve ingress-filtering for the "IPv6 site which
has two prefixes and two ISPs", and possibly three or four; the goal
here is to make sure that new connections "just work". The second task
is to define additional support mechanisms for multi-homing; the
emphasis will be on "taking advantage of multi-homing" so things work
"better", e.g., ensure that connections survive a re-homing event.

-- Christian Huitema

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 17 Mar 2004 09:09:21 -0800 (PST)

> "better", e.g., ensure that connections survive a re-homing event.

Agreed.

Perhaps we should add something to think-about and the architectural analysis
of that appears to be focused on the second task, to ask what impact different
approaches to that task might have on different approaches to the first task.

For instance, some approaches to the second task might need a solution
to ingress filtering. This prersumably means we want a good, long-term solution
for ingress filtering etc. Other approaches to the second task might instead
use locator rewriting which probably means we don't need to heavily optimize
the ingress filtering solution.

  Erik