Re: draft-ietf-multi6-multihoming-requirements-03

[Iljitsch van Beijnum <iljitsch@muada.com>]

On Tue, 2 Jul 2002, Brian E Carpenter wrote:

> I wonder why we are using MUST (upper case) terminology in any case.

Don't ask me, I think there are too many caps in the world anyway.

> Also "None of them is optional,
> but they can be omitted..." makes my head hurt.

It was the best I could come up with. It's your turn now.  :-)

> Why not just change the
> language in the whole document to must/should (lower case)?

I'm all for that. But that doesn't mean the sentence above can be omitted.

> > I don't think this is the intention, but it _can_ be read as if IPv4
> > multihoming has the capability to direct traffic for certain applications
> > over one link and traffic for other applications over another link. Since
> > this is certainly not the case, at least the example should go, possibly
> > the whole thing. (Does it require anything useful anyway?)

> Yes. Today this sort of policy is generally implemented by fiddling with
> DNS entries and addresses. Maybe we can do better for IPv6 if we think about
> it.  The example is a valid *requirement* but it should be cited
> in the IPv6 context.

I am currently multihomed in IPv6 (you have to practive what you preach)
by having two tunnels, each with address space associated with them. I am
only allowed to send out packets with source addresses A over tunnel A,
and source addresses B over tunnel B. This makes some sense, but it breaks
the hop-by-hop forwarding paradigm. It would be good if there were
something better to say about this than "if you do, I'll just filter them,
ha ha". And if we require routers to look at source addresses, why not
protocols, ports and diffserv code points as well? But I'm pretty sure
this isn't something that should be solved in this document at this time.