Re: [Dhcpv6bis] PPPoE/DSL use of DHCPv6

["Bernie Volz (volz)" <[e-mail]>]

Comments inline below (BV>).


-          Bernie

From: Dhcpv6bis [mailto:[e-mail]] On Behalf Of Ted Lemon
Sent: Wednesday, May 11, 2016 1:21 PM
To: Michael Richardson <[e-mail]>
Cc: [e-mail]
Subject: Re: [Dhcpv6bis] PPPoE/DSL use of DHCPv6

In order for two DHCP servers to share the same DUID, it would be necessary that they also share the same database, in a synchronous manner so that either server could always answer the same question the same way.

BV> Yes. I always wondered if for DHCPv6 failover we should have a “failover DUID” (same for both failover partners) that would allow RENEWs to be handled by either server. But we have never really discussed and there could be some drawbacks. So, for now left it alone. The existing separate server-ids (DUIDs) works fine. It is less efficient when one server is down for extended periods (as the Renews generated by clients trying to reach it are ignored), but ideally neither server is offline for long!!

On Wed, May 11, 2016 at 1:01 PM, Michael Richardson <[e-mail]<mailto:[e-mail]>> wrote:

<#secure method=pgpmime mode=sign>

I started my previous email with some thoughts/questions about the DSL
case.  Some of my edits added some additional references to 7084 and
Broadband Forum's TR-187.

I wanted to write/ask some higher level questions.


My background:
  In my DHCPv6 server implementation for (FinePoint ServPOET) PPPoE use, I run
  a very minimal DHCPv6 server on each gateway router. (Not a relay
  agent!). This multi-interface server receives configuration information from
  the PPPD which has done the round trip with the radius server.
  I understand that some other implementations do an additional round trip
  with the radius server, I'm not sure I understand how that works.
  I know that there are Relay Agent options which can be used to by pass
  things received by PPP from the radius server to a central DHCP server.

For me, leases come from the radius server, and are the perogative of the
radius server. My DHCP server doesn't manage any pools, etc...
The DHCPv6 process also serves as Route Advertiser for the ppp link.

A DUID-UUID is generated system-wide upon first use.

1) It occurs to me that in a cluster situation (where multiple PPPoE servers
   listen for the PPPoE PADT and respond in a way to balance load), that
   perhaps the DUID should be shared across all of the PPPoE servers, as (at
   the PPP layer) the client can be serviced by any member of the cluster.
   This is what would happen were the DHCP server centralized, but I'm pretty
   sure that if there were redundant DHCP servers that the server DUIDs would
   unique.

2) Can the returned non-temporary IA_NA returned by the DHCPv6 server be the
   same address as would be generated by SLAAC?  Clearly RA doesn't actually
   generate the address, and given stable private addresses the CPE device
   could well come up with a different address, but is the IA_NA allowed
   to be the same?

BV> While it COULD be, it does create some more complex issues if a prefix is set to also allow auto-configuration. I’m not sure how common this is today (it was used a bit more early on before there were many DHCPv6 clients). Android’s lack of DHCPv6 may still force some places to do this. And, there is a v6ops or 6man draft that I think indicated that this caused issues for certain operating systems. (Our server does have an knob (default is disabled) to do this, and some customers used it .. but I think they’ve all moved away from doing so.)

BTW: I’m also not sure how you would know the SLAAC generated address in the PPP case. When packets are relayed from Ethernet, it is easy since the Relay-Forw’s peer-address has that in it. Perhaps you are trying to extract the mac-address from the Client ID (DUID). If so, I think that is very bad.


   Radius defines PW_FRAMED_IPV6_PREFIX for the PPP link itself, and nothing
   stops this from being a /128, AFAIK.

   Should we say something about this situation?
   (I neither help the radius admin to shoot themselves in the foot, nor
   prevent it)

BV> Where do you want to say something? I don’t think this belongs in RFC 3315 bis. And, I’m not even sure what situation you are referring to. And, with the move to randomly generated mac-addresses and thus DUIDs, I’m not sure what value using the SLAAC would have.


   More and more, I'd like to suggest that for the common 7084 situation
   that the PPP link not be numbered at all with public addresses
   (link-local), and that the CPE should pick an address from one of it's
   PD-delegated LAN IPs to use for traffic that it sends.
   (I rather wish that the IETF had authored TR-187)

   As such, I'd expect the RA to say M=1,O=1 and avoid having a PIO option
   at all, signaled by lack of a PW_FRAMED_IPV6_PREFIX, and for the DHCPv6
   server to decline to do IA_NA assignment, but offer IA_PDs.

3) I probably had a third point, which I'll remember when I get further
   in the document :-)

--
Michael Richardson <[e-mail]<mailto:[e-mail]>>, Sandelman Software Works
 -= IPv6 IoT consulting =-



_______________________________________________
Dhcpv6bis mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dhcpv6bis