Re: [Dhcpv6bis] PPPoE/DSL use of DHCPv6

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

Michael:

I suspect in PPP you also have control over the RAs sent on the PPP link (if there is even one). So, I think if you are sure that SLAAC would not be used for a client end of the PPP link, I think you're OK to have the DHCPv6 server provide the "SLAAC" (or RFC7217) address to the client (of course, the SLAAC won't work if there are multiple IA_NAs for all but one of them).


FYI - Or perhaps https://tools.ietf.org/html/draft-gont-dhcpv6-stable-privacy-addresses-01  .... as Fernando is still working on this draft.

- Bernie

-----Original Message-----
From: Dhcpv6bis [mailto:[e-mail]] On Behalf Of Michael Richardson
Sent: Wednesday, May 11, 2016 5:33 PM
To: [e-mail]
Subject: Re: [Dhcpv6bis] PPPoE/DSL use of DHCPv6


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

In the PPPoE/DSL situation, the Renews go onto the PPP link can only be seen by the gateway/router aggregator.  If the aggregator is up, the DHCP server on that same machine is probably up.  There is no shared media.

In the situation where it is really a DHCP relay agent, and the relay agent uses the ALL DHCP servers multicast to reach an appropriate server (vs unicasting directly to the server it knows is up), then it seems that the Renews would also be lost even if the correct server is up.


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

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

No, that's not it at all.... PPP doesn't have MAC addresses at all.

PPP creates link-local addresses as part of IP6CP. Both ends know the exact address created, and therefore know what SLAAC would produce if applied.

see:  https://tools.ietf.org/html/rfc5072#section-4.1

From client side logs:
Wed May 11 21:12:20 2016 daemon.notice pppd[1224]: local  LL address fe80::ec41:c689:aeaa:5130 Wed May 11 21:12:20 2016 daemon.notice pppd[1224]: remote LL address fe80::021e:68ff:feb7:9688

ifconfig on client router:
pppoe-wan Link encap:Point-to-Point Protocol
          inet addr:10.10.223.7  P-t-P:10.0.0.1  Mask:255.255.255.255
          inet6 addr: 2620:120:9001:31f::5544/128 Scope:Global
          inet6 addr: 2620:120:9001:31f:ec41:c689:aeaa:5130/64 Scope:Global
          inet6 addr: fe80::ec41:c689:aeaa:5130/10 Scope:Link

my radius server returned PW_FRAMED_IPV6_PREFIX containing ...::5544 , which is why it is like that.  (

(naw, you can't ping6 those IPs right now, the OSPF router for this test instance is powered off)

RFC5072 section suggests that these link-local addresses be consistent across invocations, and my concentrator uses an eui48 from an ethernet device to accomplish this.  But, openwrt doesn't do that. Whether intention or omission I'm not sure.  Unclear to me if it's good or not.

From client side logs:
Wed May 11 21:17:23 2016 daemon.notice pppd[1535]: local  LL address fe80::3d52:f20f:5196:8f72 Wed May 11 21:17:23 2016 daemon.notice pppd[1535]: remote LL address fe80::021e:68ff:feb7:9688

the point is that for any given invocation, one can know the EUI-64 easily, and using a single address for both.


    > 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
    BV> 3315 bis. And, I’m not even sure what situation you are referring
    BV> to.   And, with the move to randomly generated mac-addresses and thus
    BV> DUIDs, I’m not sure what value using the SLAAC would have.

I think that there is zero privacy advantages for a customer CPE device to have a randomly generated lower 64-bits while the upper-64 bits remain constant.  There are significant operational downsides if the CPE device changes address every time it restarts it's PPP connection (and few PPPoE connections stay up for more than 24 hours in my experience), and I think that ISPs will use use FW_FRAMED_IPV6_PREFIX to set the CPE devices address.

The question then becomes: is it okay if the provided DHCPv6 address matches an address generated by SLAAC and/or rfc7217 "Semantically Opaque Interface Identifiers".
It's not that the server would *AIM* for that, but rather, how should the client react?


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