Re: [Dhcpv6bis] PPPoE/DSL use of DHCPv6

[Michael Richardson <[e-mail]>]

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 =-