Re: [EXTERNAL] Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements

[Michael Richardson <[e-mail]>]

Templin (US), Fred L <[e-mail]> wrote:
    >> Can you explain how such a device would normally work for a client device
    >> A,B,C,D doing DHCPv6-PD through it?

    > Sure. A sends a DHCPv6 Solicit using its IPv6 link-local address as the source,
    > and its L2 address as the link-layer source. The proxy converts the link-layer
    > source to its own L2 address when forwarding the DHCPv6 solicit onto the
    > upstream link. When the DHCPv6 Reply comes back, the IPv6 destination is
    > that of client A, but the link-layer destination is the L2 address of the proxy.
    > The proxy then converts the L2 destination to the address of client A and
    > forwards it on to the client.

But, how does the proxy know how to forward the prefix that A gets on to A?

The router, having seen A's L2 address on the DHCPv6-PD, and/or having done a
ND on A and receiving L2's address, will punt the traffic to the proxy.
Wouldn't the proxy have to observe the DHCPv6-PDs to know what prefixes are
being delegated?
I didn't think that was a thing.  I think that it just doesn't work.

If it is a thing, then the Proxy will have an L3 route for the prefix that
was delegated so that it can forward traffic from R on to A.

    >> And is the failure one where the router "R" fails to drop traffic it should,
    >> one where the router "R" drops traffic that it shouldn't?

    > I was thinking more along the lines of the latter; if the only way that A has
    > for talking to B, C, D, etc. is by going through R, it wouldn't work if R was
    > unconditionally dropping everything.

If A and B are behind the same Proxy, and each has a prefix delegated to them, and
they have to go all the way to R to get traffic forwarded because they see
R's RAs, not ones that the Proxy has made up, then indeed, R would see the
Proxy's L2 address as src/dst, and it should drop traffic.

But, I would claim that the Proxy should have seen the traffic to R,
intercepted it, and used it's routing table to get the Prefix-A/Prefix-B traffic to B.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide