Am 15.11.2012 13:09, schrieb Brian E Carpenter:
On 15/11/2012 10:19, Mattia Rossi wrote:
On Thu, Nov 15, 2012 at 9:16 AM, Brian E Carpenter <
[email protected]> wrote:
On 14/11/2012 22:44, james woodyatt wrote:
On Nov 14, 2012, at 13:34 , Mikael Abrahamsson <[email protected]> wrote:
I've always seen it to be solved via some kind of source based routing
automatically discovered between the ISP routers.
My point is that it isn't sufficient to handle this problem at just the
routers. At a minimum, the *hosts* need to be told which default router to
use with each source prefix.
Of course. I suggested this when MIF started out, and it's a MIF
issue still.
The hosts do already select the correct router depending on the prefix.
They're tied together. An RA contains a prefix and router address. That's
what the host keeps in memory.
Where is that specified? And what if the network is using DHCPv6
to provide such information?
The strongest statement I can find in RFC 6724 about this is a
MAY in section 7, which doesn't make this predictable.
It's exactly that section. The MAY obviously leaves a lot of room there.
About DHCPv6 I don't know as I haven't tried that. Good question.
If it's two RA's one router becomes default, the other more specific.
The two might be of equal standing and both offer a route to ::/0.
Well, actually true.. So, yes you're right, source based routing in the
host should become a MUST.
The
host/applications will also only use one prefix at a time, thus always send
the packets down the correct path.
I don't believe that is fully specified either. Each new socket
might make a new choice.
Different apps might use different addresses, the same app probably not.
They would reuse the same socket options all the time I believe. Anyhow,
this is just what I've observed so far. It's not how it probably
should/could be.
In my experience it was always the same prefix, the one that got registered
first (if no preference was setup in the advertising router).
If the host is connected via two or more interfaces (so we're in MIF area
now), there will always be one preferred prefix, and interface, and the
outgoing routing will work.
Then why is MIF still arguing?
Because this behaviour is not ideal. It's what I've observed, and
probably the result of an unfinished implementation due to lack of
specification. Somebody had to fix things somehow.
If applications are able to chose a specific prefix (e.g. VPN) they usually
implement some source routing on the host anyways, and send the packets to
the router registered with that prefix.
Sure, but we are worried here about zero-conf defaults.
Yes. Source based routing a MUST. I agree.
If you have an application listening for incoming connections, then it's
important that the application is smart enough to use the address on which
the incoming connection arrived as source address, and not the default one
which might be on a different prefix to avoid asynchronous communication.
As far as I know this is already common practice.
Not good enough - it needs to be specified.
I agree. That might be something to add to RFC 3484. Unless it's
already in there, but I couldn't find it.
So I don't really see a
problem here, unless you want to do some fancy load sharing and play ping
pong with source addresses.
If there's only one interface which connects to a multihomed router, the
principle is the same, but the multihomed router must be able to perform
source address routing, and forward the packets down the right path. And
this is something I'm not too sure about routers can currently do.
Indeed. Again, this needs specifying, as does behaviour when
there are multiple routers and one of them receives a packet
that should exit via another one.
https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat/
Ah, something new to read.
Thanks,
Mat
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
