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

Bob, several messages back it was established that the issue at the heart of this
discussion is not specific to DHCPv6 nor DHCPv6-PD. Instead, it is an issue that is
common to any situation where there are multiple "stub" IPv6 routers on a
downstream link from a "default" IPv6 router, no matter how the routing
information is established or maintained. So far, no one has challenged my
assertion that this is a generic (and not a DHCPv6-PD-specific) IPv6 issue and
I have been waiting to see if anyone wants to challenge that.

Fred

> -----Original Message-----
> From: Bob Hinden [mailto:bob.hinden@gmail.com]
> Sent: Wednesday, October 14, 2020 2:47 PM
> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> Cc: Bob Hinden <bob.hinden@gmail.com>; Michael Richardson <mcr+ietf@sandelman.ca>; dhcwg <dhcwg@ietf.org>; IPv6 List
> <ipv6@ietf.org>; v6ops list <v6ops@ietf.org>
> Subject: Re: [EXTERNAL] [dhcwg] [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-
> requirements
> 
> With my chair hat on, is there a reason why this discussion is being copied to the 6MAN w.g.?   6MAN doesn’t maintain DHCP related
> items.
> 
> Please remove ipv6@ietf.org from this thread.
> 
> Bob
> 
> 
> > On Oct 14, 2020, at 12:19 PM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
> >
> > Hi Michael,
> >
> >> -----Original Message-----
> >> From: Michael Richardson [mailto:mcr+ietf@sandelman.ca]
> >> Sent: Wednesday, October 14, 2020 11:58 AM
> >> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> >> Cc: ianfarrer@gmx.com; Jen Linkova <furry13@gmail.com>; dhcwg <dhcwg@ietf.org>; v6ops list <v6ops@ietf.org>; 6man
> >> <ipv6@ietf.org>
> >> Subject: Re: [EXTERNAL] Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-
> relay-
> >> requirements
> >>
> >>
> >> Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
> >>> Michael, what I was referring to below as "failure" is the proxy case when
> >>> there is an L2 proxy P between the client and relay (e.g.,
> >>> RFC489). There
> >>
> >> RFC4389 describes an ND Proxy.
> >> Is that really an L2 proxy?
> >
> > Yes, I believe it is an L2 proxy.
> >
> >> It seems like it also must be contain either an L2-bridge, or must have the
> >> L3-routing table entries if it would really be capable of passing DHCPv6-PD
> >> prefixes through it.
> >
> > The only thing it has that includes L3 information is neighbor cache entries that
> > keep track of the client's actual L2 address on the downstream link segment,
> > but rewrites the client's L2 address to its own L2 address when forwarding
> > onto an upstream link segment. (In the reverse direction, it receives packets
> > destined to its own L2 address but the client's L3 address on the upstream
> > link segment, then rewrites the L2 address to the client's L2 address when
> > forwarding onto the downstream link segment.)
> >
> >> 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.
> >
> >> 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.
> >
> > Thanks - Fred
> >
> >> --
> >> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
> >>           Sandelman Software Works Inc, Ottawa and Worldwide
> >>
> >>
> >>
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------