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

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 15 Oct 2020 19:30:55 +0000

Eduard,

Thanks for your message. The point I was trying to make is that if the upstream router
R is convinced - through whatever means - that the downstream stub router S holds
an IPv6 prefix such as 2001:db8:a:b::/64, then it will forward all IPv6 packets with
destination address from that prefix to S *even if the packets originated from S*.
That is not a new issue brought about by DHCPv6, since it is  a forwarding plane
issue and not a control plane issue.

Fred

> -----Original Message-----
> From: Vasilenko Eduard [mailto:[email-masked]]
> Sent: Thursday, October 15, 2020 12:12 PM
> To: Templin (US), Fred L <[email-masked]>
> Cc: v6ops list <[email-masked]>; IPv6 List <[email-masked]>; Michael Richardson <[email-masked]>; dhcwg <[email-masked]>
> Subject: RE: [EXTERNAL] [dhcwg] [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-
> requirements
> 
> Hi Fred,
> You need the challenge. OK. I have it for you.
> 
> Typical routing protocols would distribute to the "stub" router information about prefixes "somewhere in the network".
> Prefixes from local interfaces are inserted into the routing table in the very persistent way:-)
> 
> DHCP-PD would distribute to the "stub" router information about prefixes that should become local/interface prefixes on the "stub".
> Non-graceful reload could lead to amnesia on the "stub". Then it could attack its own uplink.
> It is a new problem. Because DHCP-PD does play the role of "automatic provisioning system", not routing protocol.
> The problem could be called "non-consistent routers configuration".
> The fact that proper protocol for prefix distribution should be very similar to routing protocol - is the secondary here (it is
> implementation), because the problem itself is new.
> 
> Eduard
> > -----Original Message-----
> > From: ipv6 [mailto:[email-masked]] On Behalf Of Templin (US), Fred L
> > Sent: 15 октября 2020 г. 1:37
> > To: Bob Hinden <[email-masked]>
> > Cc: v6ops list <[email-masked]>; IPv6 List <[email-masked]>; Michael Richardson
> > <[email-masked]>; dhcwg <[email-masked]>
> > Subject: RE: [EXTERNAL] [dhcwg] [v6ops] Re: Question to DHCPv6 Relay
> > Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements
> >
> > > I note that the lack of “challenge” does not mean anyone agrees.   Agreement
> > needs to be affirmative.
> >
> > Fair enough, Bob; here is the assertion I made that I was referring to:
> >
> > + BTW, I am still waiting to hear how this concern is in any way
> > + specific to prefix delegation, since it seems to be generic to any
> > + case of having a “stub” router that maliciously attacks its own
> > + upstream link – no matter how that router negotiates its prefixes with
> > upstream network nodes.
> >
> > Do the individuals CC'd on this list agree that this is a generic IPv6 issue and not a
> > DHCPv6-PD-specific issue?
> >
> > Thanks - Fred
> >
> > > -----Original Message-----
> > > From: Bob Hinden [mailto:[email-masked]]
> > > Sent: Wednesday, October 14, 2020 3:28 PM
> > > To: Templin (US), Fred L <[email-masked]>
> > > Cc: Bob Hinden <[email-masked]>; Michael Richardson
> > > <[email-masked]>; dhcwg <[email-masked]>; IPv6 List
> > > <[email-masked]>; v6ops list <[email-masked]>
> > > Subject: Re: [EXTERNAL] [dhcwg] [v6ops] Re: Question to DHCPv6 Relay
> > > Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay- requirements
> > >
> > > I note that the lack of “challenge” does not mean anyone agrees.   Agreement
> > needs to be affirmative.
> > >
> > > Bob
> > >
> > >
> > > > On Oct 14, 2020, at 3:24 PM, Templin (US), Fred L
> > <[email-masked]> wrote:
> > > >
> > > > 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:[email-masked]]
> > > >> Sent: Wednesday, October 14, 2020 2:47 PM
> > > >> To: Templin (US), Fred L <[email-masked]>
> > > >> Cc: Bob Hinden <[email-masked]>; Michael Richardson
> > > >> <[email-masked]>; dhcwg <[email-masked]>; IPv6 List
> > > >> <[email-masked]>; v6ops list <[email-masked]>
> > > >> 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 [email-masked] from this thread.
> > > >>
> > > >> Bob
> > > >>
> > > >>
> > > >>> On Oct 14, 2020, at 12:19 PM, Templin (US), Fred L
> > <[email-masked]> wrote:
> > > >>>
> > > >>> Hi Michael,
> > > >>>
> > > >>>> -----Original Message-----
> > > >>>> From: Michael Richardson [mailto:[email-masked]]
> > > >>>> Sent: Wednesday, October 14, 2020 11:58 AM
> > > >>>> To: Templin (US), Fred L <[email-masked]>
> > > >>>> Cc: [email-masked]; Jen Linkova <[email-masked]>; dhcwg
> > > >>>> <[email-masked]>; v6ops list <[email-masked]>; 6man
> > > >>>> <[email-masked]>
> > > >>>> Subject: Re: [EXTERNAL] Re: [dhcwg] [v6ops] Re: Question to
> > > >>>> DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-
> > > >> relay-
> > > >>>> requirements
> > > >>>>
> > > >>>>
> > > >>>> Templin (US), Fred L <[email-masked]> 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 <[email-masked]>   . o O ( IPv6 IøT
> > consulting )
> > > >>>>          Sandelman Software Works Inc, Ottawa and Worldwide
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>
> > > >>> ------------------------------------------------------------------
> > > >>> -- IETF IPv6 working group mailing list [email-masked]
> > > >>> Administrative Requests:
> > > >>> https://www.ietf.org/mailman/listinfo/ipv6
> > > >>> ------------------------------------------------------------------
> > > >>> --
> > > >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [email-masked]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 16 Oct 2020 15:53:26 +0000

Eduard,

> Sent: Friday, October 16, 2020 12:20 AM
> Subject: [EXTERNAL] RE: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-
> requirements
>
> Hi Fred,
> I do not fully agree to you.

We are talking past each other, and one of us does not have a clear understanding
of the issue at the heart of the discussion which I see as a forwarding plane issue
having nothing to do with the control plane.

Thanks - Fred

> Yes, such data plane problem (like you described) could happen in the ordinary routing environment.
> Theoretically, it could be created by routing protocol (in control plane).
> Practically, all routing protocols are robust enough for such situation not to happen - they do have some means to synchronize states
> (at least tracking "neighbors").
> 
> But it is not related to DHCP-PD discussion.
> DHCP-PD is stateless without information synchronization after link up. Even "link up" is not possible to track if it is multi-hop through
> bridge.
> It is easy to create such amnesia: just push power button on the stub router.
> 
> Hence, I do not understand the point of your generalization.
> It is not proper generalization, because it does not work in all environments.
> Especially it is important that it does not work in DHCP-PD environment.
> 
> Eduard
> > From: Templin (US), Fred L [mailto:[email-masked]]
> > Sent: 15 октября 2020 г. 22:31
> > To: Vasilenko Eduard <[email-masked]>
> > Subject: RE: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay Implementors
> > regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements
> >
> > Eduard,
> >
> > Thanks for your message. The point I was trying to make is that if the upstream
> > router R is convinced - through whatever means - that the downstream stub
> > router S holds an IPv6 prefix such as 2001:db8:a:b::/64, then it will forward all
> > IPv6 packets with destination address from that prefix to S *even if the packets
> > originated from S*.
> > > Cc: v6ops list <[email-masked]>; IPv6 List <[email-masked]>; Michael
> > > Richardson <[email-masked]>; dhcwg <[email-masked]>
> > > Typical routing protocols would distribute to the "stub" router information
> > about prefixes "somewhere in the network".
> > > DHCP-PD would distribute to the "stub" router information about prefixes that
> > should become local/interface prefixes on the "stub".
> > > It is a new problem. Because DHCP-PD does play the role of "automatic
> > provisioning system", not routing protocol.
> > > The fact that proper protocol for prefix distribution should be very
> > > similar to routing protocol - is the secondary here (it is implementation),
> > because the problem itself is new.
> > >
> > > Eduard
> > > > Cc: v6ops list <[email-masked]>; IPv6 List <[email-masked]>; Michael
> > > > Richardson <[email-masked]>; dhcwg <[email-masked]>
> > > > + upstream link – no matter how that router negotiates its prefixes
> > > > + with
> > > > upstream network nodes.
> > > >
> > > > Do the individuals CC'd on this list agree that this is a generic
> > > > IPv6 issue and not a DHCPv6-PD-specific issue?
> > > >
> > > > Thanks - Fred
> > > >
> > > > > > 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
> > > > > >>>>> 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
> > > > > >>>>
> > > > > >>> 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.)
> > > > > >>>
> > > > > >>> 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
> > > > > >>>> 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
> > > > > >>>
> > > > > >>>> --
> > > > IETF IPv6 working group mailing list [email-masked] Administrative
> > > > Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: [email-masked]
Date: Fri, 16 Oct 2020 20:30:31 +0200

> having nothing to do with the control plane.

Well, the forwarding plane just does what it's told.
When you set up DHCP with static routes at both ends, which are maintained by snooping on a protocol. It's not inconceivable that there are cases where you'd get a routing loop. Good thing we have the HLIM field. ;-)

Markus' draft is still the most authorative document discussion the solution space:
https://tools.ietf.org/html/draft-stenberg-v6ops-pd-route-maintenance-00

The CPE requirements document could have had a requirement that it should never forward a packet received on the WAN interface back out the WAN interface.

Cheers,
Ole

---

From: Timothy Winters <[email-masked]>
Date: Fri, 16 Oct 2020 14:37:53 -0400

Hi Ole,

I was starting to think about that solution, but I was wondering about
multiple CPEs in the home and what things could go wrong if we didn't
allow hairpinning on the WAN.

~Tim

On Fri, Oct 16, 2020 at 2:31 PM <[email-masked]> wrote:

> When you set up DHCP with static routes at both ends, which are maintained
> by snooping on a protocol. It's not inconceivable that there are cases
> where you'd get a routing loop. Good thing we have the HLIM field. ;-)
>
> The CPE requirements document could have had a requirement that it should
> never forward a packet received on the WAN interface back out the WAN
> interface.
>
> Cheers,
> Ole

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Oct 2020 14:51:14 -0400

> The CPE requirements document could have had a requirement that it should never forward a packet received on the WAN interface back out the WAN interface.

It’s unfortunate that it doesn’t have a rule that it should never forward a packet received on the LAN interface back to the LAN interface.

I wonder what’s happening in practice. We have quite a lot of devices in the world doing DHCPv6 PD. How is it that we aren’t seeing reports of routing loops? Are they just humming away silently, consuming LAN bandwidth, or are routers already doing the right thing?

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 16 Oct 2020 20:48:59 +0000

Ole,

> back out the WAN interface.

That is what I said before, but I qualified it by saying "should never forward a packet
received on the WAN interface back out the WAN interface *via a default route*."
It could be that there are more-specific routes that would cause a packet coming
into the WAN interface to go back out the WAN interface and that is OK; but, not
via a default route.

However, the further discussion seems to suggest that the delegating router needs
to be mindful of clients that maliciously or otherwise send ping-ponged self-directed
packets. I was worried that the delegating router would not be able to distinguish
CPE router A from CPE routers B, C, D in some cases. But, I am not worried about
that anymore.

Thanks - Fred

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, October 16, 2020 11:31 AM
> Cc: Vasilenko Eduard <[email-masked]>; Michael Richardson <[email-masked]>; v6ops list <[email-masked]>;
> 6man WG <[email-masked]>; dhcwg <[email-masked]>
> Subject: [EXTERNAL] Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-
> requirements
> 
> This message was sent from outside of Boeing. Please do not click links or open attachments unless you recognize the sender and
> know that the content is safe.
> 
> 
> >
> When you set up DHCP with static routes at both ends, which are maintained by snooping on a protocol. It's not inconceivable that
> there are cases where you'd get a routing loop. Good thing we have the HLIM field. ;-)
> 
> Ole=

---

From: "Ms. Li HUANG" <[email-masked]>
Date: Tue, 27 Oct 2020 16:02:52 +0800

15:46.hk S8 Oct. 27 2020

Good Day group,

The own sg,  vlan routing to ISP dhcpv6 ?
        -  its ipv6 route told unable routed?
        -  stub insight sg or modem.isp?

The own rv ipv6 temp at ipconfig /all is AT wan, none PD possible to be set
up...
        - wan v6 would be able to package exchanging to isp dhcpv6?
        - stub on this rv?

The modem.isp only network to endpoint pc,
        -  stub on modem possible ?
        -   stub on vrrp v6 of isp ?
        -    stub at ISP behind of the client 's rv, or sg or modem ?

       none of is then, no stub package would once tried , no longer
possible to resent it as probably immediately dropped at the 1st
transformation failed right afterward ?

Sincerely
Li HUANG

On Sat, Oct 17, 2020, 04:49 Templin (US), Fred L <[email-masked]>
wrote:

> Ole,
>
> > The CPE requirements document could have had a requirement that it
> should never forward a packet received on the WAN interface
> > back out the WAN interface.
>
> > Cc: Vasilenko Eduard <[email-masked]>; Michael Richardson <
> [email-masked]>; v6ops list <[email-masked]>;
> > Subject: [EXTERNAL] Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay
> > This message was sent from outside of Boeing. Please do not click links
> or open attachments unless you recognize the sender and
> > When you set up DHCP with static routes at both ends, which are
> maintained by snooping on a protocol. It's not inconceivable that
> > The CPE requirements document could have had a requirement that it
> should never forward a packet received on the WAN interface
> > back out the WAN interface.
> >
> > Cheers,
> > Ole=
>
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>