Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

[Ted Lemon <[e-mail]>]

How does the client know in which moved a response is intended to exist.
Also, what problem are you trying to solve here?  What you described sounds
like it's just an attempt at implementing mpvd on a homenet without
requiring that all routers behave the same.

On Aug 11, 2017 6:15 AM, "Toke Høiland-Jørgensen" <[e-mail]> wrote:

> Ted Lemon <[e-mail]> writes:
>
> > On Aug 10, 2017, at 6:07 PM, Toke Høiland-Jørgensen <[e-mail]>
> wrote:
> >> Now, assuming that I am wrong and this is actually a serious issue that
> >> we need to solve (of which I am not opposed to being convinced), I think
> >> it would be feasible to come up with a solution where we could at least
> >> allow less capable routers that do not implement the full MPvD support.
> >> I can think of at least two ways off the top of my head:
> >>
> >> 1. Allow the router in question to offload queries to a more capable
> >>   router elsewhere in the homenet.
> >>
> >> 2. Allow the router in question to just query all upstreams and combine
> >>   the results (and so offload the problem to the client).
> >
> > Great.   Can you explain, step by step, how to do either of these
> > things?
>
> Given that router A supports MPvD and router B doesn't:
>
> 1a. Router A exports over HNCP that it supports MPvD. Router B forwards
>     all queries to router A, using a source address in the same prefix
>     as the original request was received from.
>
> 1b. Router A exports over HNCP that it supports MPvD. Router B uses
>     router A's address (which would need to be routable inside the
>     homenet, obviously) as the DNS server in RAs.
>
> 2. Router B simultaneously forwards the query to all upstream DNS
>    servers known to the homenet, waits for replies from N of them,
>    creates the union set of all those replies and sends that back to the
>    client.
>
> If N=1 in 2, that corresponds to just ignoring MPvD. Router B could also
> fall back to 2 if no router A is available on the network.
>
> Now, please feel free to explain why you think these would break
> things... ;)
>
> -Toke
>