Subject: [Dhcpv6bis] Wednesday's call - reminder & discuss a few "minor" tickets

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 2 May 2016 18:14:39 +0000

Hi:

I'd like to discuss the following (fairly minor) tickets during Wednesday's call as they should hopefully be fairly straightforward to resolve if we have consensus among us. If you have comments now, by all means send them as that might expedite the discussion.

137 - Move/rework sections 1.2/1.3 (& 5)? [1.2 and 1.3 are RFC 3315 section numbers! Not so sure what &5 referred to, but perhaps this was a reference to an early bis document.]
157 - Client cannot generally just 'retransmit' requests
158 - Inconsistent UseMulticast checks?
159 - Add "Client adds Elapsed Time Option" into packets

And, as a reminder, there are still a bunch of ticket on which there has been little progress. Recall that as per https://www.ietf.org/proceedings/95/slides/slides-95-dhc-5.pdf (see below), we'd like to get these all resolved by May 9th so we can publish 05 and initiate a WGLC on it.

-          Bernie

Here's what "Our Plans" were when we meet at IETF-95:

-          Reorganizing client/server sections (#142) by April 15th

*        Text being reviewed (in branch)

*        Update and merge into Github master

-          Finish most other tickets by May 9th

-          Apply editor tickets

-          Republish by May 23 (05)

-          Complete WGLC before Berlin (IETF-96)

-          Discuss any WGLC issues in Berlin and update

-          Send to IESG in September 2016

-

---

From: Michael Richardson <[email-masked]>
Date: Thu, 05 May 2016 18:01:23 -0400

I have three sets of comments.
1) some typos/verb tenses; I can git push, or send a pull request on the XML.

2) some suggestions for additional references, particularly around PD
   that I think should be in the early sections.
   I think that these should be pull requests, so you can see the diff.
   I don't think they are controversial.

3) some comments/thoughts about the PPP/PPPoE usages of DHCPv6.
   I think that these may in fact warrant tickets referencing pull requests,
   because we may need to discuss these.
   I'm only at section ~15 at this point.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 5 May 2016 22:28:33 +0000

Michael:

Yes, update the github document. We can look at diffs. If you have
controversial issues or more significant changes, perhaps best to discuss
those first — one way would be to open tickets?

- Bernie

---

From: Michael Richardson <[email-masked]>
Date: Wed, 11 May 2016 12:48:38 -0400

Is a version of xml2rfc newer than 2.5.1, which maybe permits <street>
to be omitted?  I had to add <street></street> to Tim Winter's address
to get xml2rfc to pass.  I didn't find a version newer than 2.5.1.

Please forgive this stream-of-consciousness email, I haven't made
edits for all of my comments, because some of them I don't know what to do.
I can turn them into tickets if desired.

Also, the .xml file has lots of trailing whitespace which is generally
a bad idea in git, as it sees that as gratuitous changes.
Commit: 5117803 cleans that up.

I've created a branch: mcr_review_201605 with my commits.
You may git merge, or git cherry-pick as it suits.
  https://github.com/dhcwg/rfc3315bis/compare/mcr_review_201605?expand=1

* I think that the figure and associated description in section 5.3 (prefix
  delegation), should be moved into section 5.4 (DHCP for Customer Edge Routers)
  commit ID:

On the text (section: 10.0):
   The motivation for having more than one type of DUID is that the DUID
   must be globally unique, and must also be easy to generate.

I wonder if: MUST be globally unique?  I suspect that we want SHOULD here
though, if we upcase it.

re: text
    The sort
    of globally-unique identifier that is easy to generate for any given
    device can differ quite widely.  Also, some devices may not contain
    any persistent storage.  Retaining a generated DUID in such a device
    is not possible, so the DUID scheme must accommodate such devices.

I'm bothered by "Also, ..." not as a concept, but just as easy to understand English.

* I think that UUID-based DUIDs should get a section, even if it's rather
  empty, and I added one, commit-ID:

section 11:
  - when we speak about "A client", I think we really mean "A client system"
    rather than "a client dhcp instance".   I say this because I think that
    the common use on Linux of Network Manager and Android to spawn off
    multiple dhclient instances for each interface is incorrect.  They likely
    pick different DUIDs, and also I don't know if they re-use the constant IAID
    across multiple interfaces.
    I'm not sure if MIF says anything about multiple provisioning domains.
    How can a client *know* when it's speaking in multiple provisioning
    domains, or when it should treat (bridged) wifi and ethernet as if it was
    the same domain?

section 13.1: is nice advice on how clients should behave.
    But:
                Rate limiting of forwarded DHCP messages and server-side
                messages are out of scope of this specification.
    seems to beg for a security review red flag!

section 14:

   >A client is not expected to listen for a response during the entire
   >period between transmission of Solicit or Information-request
   >messages.

   I don't understand this.  is it saying that client can go into low-power
   mode?
   I think it's saying that after receiving a reply, (or timing out receiving
   one), that a client can ignore DHCP messages until it is interesting in a
   (trying) a renewal again.

section 17:
   "The client which is performing..."
    found english awkward, commit: 0f86fc0

   also, deleted later paragraph that
   "If the client will accept a Reply message with committed leases..."

   probably the whole rapid commit discussion should go in a single place?
   probably the next paragraph, "Servers that can assign..." should be moved
   too?

   Split the reasons for initiating configuration exchange into numbered
   list, for future reference: commit: 528f53f

section 1.4/1.5 and 17 intentionally overlap, but I don't feel that
the introductory sections set the stage for section 17 well enough.

Why do we write this:

   The client MUST NOT be using any of the
   addresses or delegated prefixes for which it tries to obtain the
   bindings by sending the Solicit message.  In particular, if the
   client had some valid bindings and has chosen to start the server
   solicitation process to obtain the bindings from a different server,
   the client MUST stop using the addresses and delegated prefixes for
   the bindings it had obtained from the previous server, and which it
   is now trying to obtain from a new server.

are we really saying that this is a break-before-make situation?
Is there a reason for this?

There is a LOT of information in section 17; it seems almost like a random
assembly of things...  We have section 17.1

section 17.1:
   When a client detects it may have moved to a new link, it uses
   Confirm if it only has addresses and Rebind if it has delegated

... I'm not sure what the correct behaviour is for a virtual PPP link,
    such as DSL/PPPoE.   In the field, I do not observe this behaviour
    from dnsmasq.  It starts with Request every time the link drops.

    added some text about faked Reconfigure messages.

re: DISCUSSION, do we have any field experience that enabling unicast
    communication is really occuring, and really has useful benefits?
    a) Could this be something that we might drop based upon the belief
       that DHCP relay agents provide useful information?
    b) if it is multicasting and message duplication that we care to avoid,
       could the client be told to unicast to the DHCP relay?

I think that the 17.1.1 text about Rapid Commit is too convoluted.
I would like either section 17.1.1 or 20.14 to say more about why the client
would use the Rapid Commit option.  Who should use this?

I edited the Rapid Commit vs Advertise text, I think that there is an
interval missing during which the client notes the Advertise messages, but
does not act on them while it looks for a Reply-with-Rapid commit.
commit: e1509b3

The two paragraphs starting with:
   If the client is waiting for an Advertise message, the mechanism in

just seem to jump in the middle like a weird photo-bomb. I understood all the
words, but couldn't figure out what's going on.  I think that maybe it has
nothing to do with Rapid Commit, but is the primary text on how to listen to
advertise messages.

In that case, I suggest that those two paragraphs be moved upwards, and the
Rapid Commit discussion come after the "first RT" interval has been explained.
      commit: 1c9dab0

I stopped for lunch at 17.1.2, which my editor says is only 38% in.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 11 May 2016 16:51:39 +0000

I just use xml2rfc.ietf.org to do the conversions.

But, sorry I did not try the minor edit to add Tim as co-author so perhaps it does not allow a missing <street>. Thanks for fixing it.

- Bernie

-----Original Message-----
From: Dhcpv6bis [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Wednesday, May 11, 2016 12:49 PM
To: [email-masked]
Subject: [Dhcpv6bis] first email thoughts/edits on my read through

Is a version of xml2rfc newer than 2.5.1, which maybe permits <street> to be omitted?  I had to add <street></street> to Tim Winter's address to get xml2rfc to pass.  I didn't find a version newer than 2.5.1.

Please forgive this stream-of-consciousness email, I haven't made edits for all of my comments, because some of them I don't know what to do.
I can turn them into tickets if desired.

Also, the .xml file has lots of trailing whitespace which is generally a bad idea in git, as it sees that as gratuitous changes.
Commit: 5117803 cleans that up.

I wonder if: MUST be globally unique?  I suspect that we want SHOULD here though, if we upcase it.

re: text
    The sort

section 11:

section 17:

section 1.4/1.5 and 17 intentionally overlap, but I don't feel that the introductory sections set the stage for section 17 well enough.

Why do we write this:

There is a LOT of information in section 17; it seems almost like a random assembly of things...  We have section 17.1

section 17.1:

I think that the 17.1.1 text about Rapid Commit is too convoluted.
I would like either section 17.1.1 or 20.14 to say more about why the client would use the Rapid Commit option.  Who should use this?

I edited the Rapid Commit vs Advertise text, I think that there is an interval missing during which the client notes the Advertise messages, but does not act on them while it looks for a Reply-with-Rapid commit.
commit: e1509b3

just seem to jump in the middle like a weird photo-bomb. I understood all the words, but couldn't figure out what's going on.  I think that maybe it has nothing to do with Rapid Commit, but is the primary text on how to listen to advertise messages.

In that case, I suggest that those two paragraphs be moved upwards, and the Rapid Commit discussion come after the "first RT" interval has been explained.
      commit: 1c9dab0

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Wed, 11 May 2016 13:01:24 -0400

<#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?

   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)

   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 :-)

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 May 2016 13:20:34 -0400

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.

On Wed, May 11, 2016 at 1:01 PM, Michael Richardson <[email-masked]>
wrote:

> _______________________________________________
> Dhcpv6bis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcpv6bis
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 11 May 2016 17:28:35 +0000

Some more feedback inline below (prefixed by BV>).

- Bernie

-----Original Message-----
From: Dhcpv6bis [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Wednesday, May 11, 2016 12:49 PM
To: [email-masked]
Subject: [Dhcpv6bis] first email thoughts/edits on my read through

BV> This is probably just based on what editors people use. No issues in removing the trailing spaces.

I've created a branch: mcr_review_201605 with my commits.
You may git merge, or git cherry-pick as it suits.
  https://github.com/dhcwg/rfc3315bis/compare/mcr_review_201605?expand=1
BV> No need to create a branch.

BV> OK. Though perhaps the "Figure 1 illustrates ..." text should be moved too? Note that this figure came from RFC 3633 and that document just discussed PD (not address + PD). So, that's why it was with the 5.3 text. Also, RFC 7084 has a similar figure -- wonder whether moving it into section 5.4 (instead of current figure) would be appropriate?

BV> I would prefer to leave lower case since that is what RFC 3315 had. Yes, if we are to upcase, SHOULD is appropriate. I think the difference here is that this is the INTENT, but there is no way to assure it. MUST is best in cases where it is possible to do (such as setting a field to a specific value).

re: text
    The sort

BV> Do you have a suggested rewording? Perhaps this should be "As some devices may not contain [any] persistent storage, retaining a generated DUID in these devices is not possible, so the DUID scheme must accommodate such devices.".

BV> must -> MUST/SHOULD here too? Again best to leave it be?

BV> No, we just want to mention it but leave the details to the RFC itself. We don't want to suck that RFC into this one. If you feel we need a "10.5 DUID Based on Universally Unique Identifier, DUID-UUID", I would just have it say "This identifier is fully described in RFC 6355" (or something close to that).

section 11:

BV> I would suggest that having a "global" IA space across all interface is important since a client cannot know how the network is configured and whether two interfaces are connected to the same link (and server). So, we have to be careful here. I agree that this is a bit vague. Perhaps some text that describes the "global" IA space is useful?

BV> Perhaps. Forwarded packets depend on what packets clients or servers (in aggregate) generate. Rate limiting here is really more difficult as it depends on what the relays and servers can support. So, I think it best for us not to get into that? For server generated messages, those are the Reconfigure messages and a server only harms itself (and relays) if it floods the network? So, again I think this is best not discussed. I wonder if we should just remove this sentence (rather than opening this up for comment).

BV> Yes. Basically the client if the client is supposed to wait 60 seconds to transmit, it doesn't have to "listen" for incoming packets for that entire period. So, it can go into lower power mode. Note that the SOL/INF_MAX_RT make these periods even longer (3600 seconds if I recall). Would changing "transmission" to "transmissions" help any?

section 17:

BV> Will have to look at this more carefully.

BV> Correct. See ticket #137 (which I closed just a few days ago).

Why do we write this:

BV> Because a SOLICIT means that you aren't using those items - they are just HINTS to request them. If a client is actually using those, it should be sending a RENEW or REBIND.

section 17.1:

BV> Hope it starts with Solicit? Anyway, use of Confirm and Rebind just avoid the issue with above Solicit means stop using the addresses/delegated prefixes. 

BV> I don't think we should remove this capability. In many cases (such as CableLabs DOCSIS), they specifically always want the Relayed packets since there is critical information to validate requests. I'm not aware of much usage of unicast.

BV> I'll leave it for Marcin to perhaps comment (about convoluted text). Again, CableLabs DOCSIS indicates CM clients should request Rapid Commit (though server doesn't have to honor it). It saves traffic, and by client always requesting it, server can be configured to allow or not.

BV> I don't think this is necessary. Rapid-Commit Reply implies there are no other servers.

BV> Probably OK.

BV> Enjoy your lunch! And, THANKS VERY MUCH for your work on this. (I did print out the document two days ago and will be reading through it; but perhaps I should consider printing a fresh copy - but perhaps best to wait until you've reviewed with other 62%.)

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 11 May 2016 17:41:16 +0000

Comments inline below (BV>).

-          Bernie

From: Dhcpv6bis [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Wednesday, May 11, 2016 1:21 PM
To: Michael Richardson <[email-masked]>
Cc: [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:

My background:

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.

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.

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

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 11 May 2016 16:59:34 -0400

> either server could always answer the same question the same way.

Given that both devices get all their leases from the (cluster) of radius
server(s), it would seem that this is already satisfied.

The question is perhaps: MUST those servers have the same DUID?

---

From: Michael Richardson <[email-masked]>
Date: Wed, 11 May 2016 17:33:16 -0400

Bernie Volz (volz) <[email-masked]> 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.

    > could well come up with a different address, but is the IA_NA allowed

    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.

    > (I neither help the radius admin to shoot themselves in the foot, nor

    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?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 11 May 2016 21:46:39 +0000

> The question is perhaps: MUST those servers have the same DUID?

No, there is no such requirement. Things will work fine if they have different server-ids.

Failover doesn't use the same DUID for the servers.

- Bernie

-----Original Message-----
From: Dhcpv6bis [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Wednesday, May 11, 2016 5:00 PM
To: Ted Lemon <[email-masked]>
Cc: [email-masked]
Subject: Re: [Dhcpv6bis] PPPoE/DSL use of DHCPv6

    > either server could always answer the same question the same way.

Given that both devices get all their leases from the (cluster) of radius server(s), it would seem that this is already satisfied.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 12 May 2016 18:23:59 +0000

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:[email-masked]] On Behalf Of Michael Richardson
Sent: Wednesday, May 11, 2016 5:33 PM
To: [email-masked]
Subject: Re: [Dhcpv6bis] PPPoE/DSL use of DHCPv6

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.

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.

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

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.

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?