Subject: [Dhcpv6bis] FW: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 19 Jan 2017 21:50:55 +0000

FYI … Not sure you’ve been following this lengthy debate on the v6ops mailing list.

But I just wonder if there is more we should do in 3315bis to make it much clearer that DHCPv6 is much more flexible and capable than I think people assume.

Perhaps it is too late and the battle has been lost on DHCPv6 for address assignment for at least mobile devices …

BTW, if you haven’t seen it, it is worth watching Geoff Huston’s talk at Ripe - https://ripe71.ripe.net/archives/video/1343/. Someone forwarded me this (in a private discussion after my email to v6ops).

-          Bernie

From: Bernie Volz (volz)
Sent: Thursday, January 19, 2017 4:46 PM
To: 'Lorenzo Colitti' <[email-masked]>
Cc: v6ops list <[email-masked]>
Subject: RE: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem

Hi Lorenzo:

I do regret not being more active when RFC 7934 was being drafted as I think there are some things about DHCPv6 that are a bit off.

          It is also technically possible for a client
      to request additional addresses using a different DHCP Unique
      Identifier (DUID), though the DHCPv6 specification implies that
      this is not expected behavior ([RFC3315], Section 9<https://tools.ietf.org/html/rfc3315#section-9>).

The way a client can get many addresses is simply to send in multiple IA_NA (or IA_TA or IA_PD) options with different IAID values. There is no need to change the DUID.

           The maximum number of IPv6 addresses that can be provided

      in a single DHCPv6 packet, given a typical MTU of 1500 bytes or

      smaller, is approximately 30

But a client is free to send many separate transactions (multiple packets). For example, one approach would be to send a new request whenever a new address is needed – this would be an IA_NA (for non-temporary address) with a unique IAID. And, that might be much easier when you have dynamic needs (i.e., device being added over time).

And, each transaction does not need to start with the server discovery process since that has already been done – they can start with a Request (2 message exchange).

Sadly, we may have made things even a bit worse with the introduction of RFC 7550 as this promotes using a single transaction when asking for multiple things (IA_NA + IA_PD is the classic example). But the goal of RFC 7550 was to make the Customer Edge (CE) router (described in RFC7084) model simpler – especially in cases where not both an address and delegated prefix might be available. And, if doesn’t precluded the separate transaction model.

Neither of the statements in the RFC is technically wrong (as changing the DUID is certainly one way to accomplish that goal, and the limit for a single packet is correct). But it just leaves the wrong impression about DHCPv6. We designed it to allow LOTS of addresses per client and be very flexible in how those addresses are “grouped” (i.e., by IA_* type and IAID).

And, yes this is more code and overhead to just having a /64 available and building an address whenever it is needed (that’s a few lines of code to write and execute) – no extra external communication necessary.

-          Bernie

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Thursday, January 19, 2017 12:43 PM
To: Bernie Volz (volz) <[email-masked]>
Cc: Chuck Anderson <[email-masked]>; Fernando Gont <[email-masked]>; v6ops list <[email-masked]>
Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem

Bernie,

have you read RFC 7934? It lists a number of reasons why it is not recommended for networks to support only DHCPv6 address assignment via IA_NA.

I don't think DHCPv6 in itself is a problem. While it does suffer from the limitations I outlined in my earlier message, it is flexible and extensible to way more information than RAs can carry. It's also widely supported. But I really think IA_NA is not appropriate for IPv6 assignment, for the reasons that the authors and the WG outline in RFC7934.

Unfortunately, for many, decades of operational familiarity and vendor support with IPv4 networks, where the only way to get an IP address (and only ever ONE address) was DHCP, make it very hard to think of any other address assignment mechanism. SLAAC is regularly dismissed as outlandish and insecure, /64 subnets as wasteful, and the insistence that IPv4 and IPv6 demand different link-addressing practives as religion. "Why can't we just use DHCP", as an earlier message put it. Unfortunately the truth is much more complex than that.

If the Internet is eventually to reap the full benefits of IPv6, then we as a technical community and as an industry need to give a chance to a new addressing model where hosts can use as many IPv6 addresses as they need. Right now, that means SLAAC. The fact of the matter is that it SLAAC's security properties are not substantially worse than IA_NA, and anyone who says differently should read RFC 7934 section 9.1, of which I have not yet seen any rebuttal, convincing or otherwise. And as for /64s being wasteful - you saw the earlier messages in this conversation that asserted that prefixes cost money or they are hard to obtain, when in fact the cost is orders of magnitude lower than one cent, and RIR policies ere extremely liberal?

It would be extremely easy to simply carry over practices that we have in IPv4 to IPv6. But because applications are incentivized to add application complexity in order to work properly on all networks, there is a risk that we might get stuck there, and never be able to elevate ourselves out of those practices. If that happens will keep suffering the problems caused by IP address scarcity even after scarcity is banished. That would be a bad outcome.

Of course I may be wrong and a one-address-per-host model is the right choice. But I don't think we can tell at the moment. Over the years, network administrators that learn about IP (and application developers that write applications) on dual-stack networks with a mix of SLAAC and DHCPv6 will be able to make better choices between these protocols than we can today.

Cheers,
Lorenzo

On Fri, Jan 20, 2017 at 1:59 AM, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:
While I probably shouldn't send this as it is in the political and not technical space, I frankly am very disappointed in one company that, while trying to promote IPv6 usage, has also worked very hard to limit its use by NOT supporting a protocol developed by the IETF.

I'm also surprised that organizations haven't pushed harder to get that company to implement the standards. I suspect though that is because IPv6 is not yet "critical" for deployment. This provides the company an opportunity to push their agenda (whatever it may be).

I will admit that being DHC WG co-chair, coauthor of the some of the standards, and also a vendor does bias me.

- Bernie

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 19 Jan 2017 21:57:12 +0000

Hi Bernie,

I am using DHCPv6 PD for mobile devices. I mentioned this on the list but did
not see a response. Is this something we want to state more clearly?

Thanks - Fred

From: Dhcpv6bis [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Thursday, January 19, 2017 1:51 PM
To: [email-masked]' <[email-masked]>
Subject: [Dhcpv6bis] FW: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem

-          Bernie

From: Bernie Volz (volz)
Sent: Thursday, January 19, 2017 4:46 PM
To: 'Lorenzo Colitti' <[email-masked]<mailto:[email-masked]>>
Cc: v6ops list <[email-masked]<mailto:[email-masked]>>
Subject: RE: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem

Hi Lorenzo:

-          Bernie

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Thursday, January 19, 2017 12:43 PM
To: Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>>
Cc: Chuck Anderson <[email-masked]<mailto:[email-masked]>>; Fernando Gont <[email-masked]<mailto:[email-masked]>>; v6ops list <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem

Bernie,

Cheers,
Lorenzo

- Bernie

---

From: Timothy Winters <[email-masked]>
Date: Thu, 19 Jan 2017 16:59:37 -0500

Hi Bernie,

I've been following this thread, I think we may want to clearly document
the ability to get multiple addresses.

~Tim

On Thu, Jan 19, 2017 at 4:50 PM, Bernie Volz (volz) <[email-masked]> wrote:

> But I just wonder if there is more we should do in 3315bis to make it much
> clearer that DHCPv6 is much more flexible and capable than I think people
> assume.
>
>
>
> BTW, if you haven’t seen it, it is worth watching Geoff Huston’s talk at
> Ripe - https://ripe71.ripe.net/archives/video/1343/. Someone forwarded me
> this (in a private discussion after my email to v6ops).
>
>
>
> -          Bernie
>
>
>
> *From:* Bernie Volz (volz)
> *Sent:* Thursday, January 19, 2017 4:46 PM
> *To:* 'Lorenzo Colitti' <[email-masked]>
> *Cc:* v6ops list <[email-masked]>
> *Subject:* RE: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem
>
>
>
> Hi Lorenzo:
>
>
>
> I do regret not being more active when RFC 7934 was being drafted as I
> think there are some things about DHCPv6 that are a bit off.
>
>
>
>       this is not expected behavior ([RFC3315], Section 9
> <https://tools.ietf.org/html/rfc3315#section-9>).
>
>
>
> The way a client can get many addresses is simply to send in multiple
> IA_NA (or IA_TA or IA_PD) options with different IAID values. There is no
> need to change the DUID.
>
>
>
> But a client is free to send many separate transactions (multiple
> packets). For example, one approach would be to send a new request whenever
> a new address is needed – this would be an IA_NA (for non-temporary
> address) with a unique IAID. And, that might be much easier when you have
> dynamic needs (i.e., device being added over time).
>
>
>
> And, each transaction does not need to start with the server discovery
> process since that has already been done – they can start with a Request (2
> message exchange).
>
>
>
> Sadly, we may have made things even a bit worse with the introduction of
> RFC 7550 as this promotes using a single transaction when asking for
> multiple things (IA_NA + IA_PD is the classic example). But the goal of RFC
> 7550 was to make the Customer Edge (CE) router (described in RFC7084) model
> simpler – especially in cases where not both an address and delegated
> prefix might be available. And, if doesn’t precluded the separate
> transaction model.
>
>
>
>
>
> Neither of the statements in the RFC is technically wrong (as changing the
> DUID is certainly one way to accomplish that goal, and the limit for a
> single packet is correct). But it just leaves the wrong impression about
> DHCPv6. We designed it to allow LOTS of addresses per client and be very
> flexible in how those addresses are “grouped” (i.e., by IA_* type and IAID).
>
>
>
> And, yes this is more code and overhead to just having a /64 available and
> building an address whenever it is needed (that’s a few lines of code to
> write and execute) – no extra external communication necessary.
>
>
>
> -          Bernie
>
>
>
> *From:* Lorenzo Colitti [mailto:[email-masked]]
> *Sent:* Thursday, January 19, 2017 12:43 PM
> *To:* Bernie Volz (volz) <[email-masked]>
> *Cc:* Chuck Anderson <[email-masked]>; Fernando Gont <[email-masked]>;
> v6ops list <[email-masked]>
> *Subject:* Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem
>
>
>
> Bernie,
>
>
>
> have you read RFC 7934? It lists a number of reasons why it is not
> recommended for networks to support only DHCPv6 address assignment via
> IA_NA.
>
>
>
> I don't think DHCPv6 in itself is a problem. While it does suffer from the
> limitations I outlined in my earlier message, it is flexible and extensible
> to way more information than RAs can carry. It's also widely supported. But
> I really think IA_NA is not appropriate for IPv6 assignment, for the
> reasons that the authors and the WG outline in RFC7934.
>
>
>
> Unfortunately, for many, decades of operational familiarity and vendor
> support with IPv4 networks, where the only way to get an IP address (and
> only ever ONE address) was DHCP, make it very hard to think of any other
> address assignment mechanism. SLAAC is regularly dismissed as outlandish
> and insecure, /64 subnets as wasteful, and the insistence that IPv4 and
> IPv6 demand different link-addressing practives as religion. "Why can't we
> just use DHCP", as an earlier message put it. Unfortunately the truth is
> much more complex than that.
>
>
>
> If the Internet is eventually to reap the full benefits of IPv6, then we
> as a technical community and as an industry need to give a chance to a new
> addressing model where hosts can use as many IPv6 addresses as they need.
> Right now, that means SLAAC. The fact of the matter is that it SLAAC's
> security properties are not substantially worse than IA_NA, and anyone who
> says differently should read RFC 7934 section 9.1, of which I have not yet
> seen any rebuttal, convincing or otherwise. And as for /64s being wasteful
> - you saw the earlier messages in this conversation that asserted that
> prefixes cost money or they are hard to obtain, when in fact the cost is
> orders of magnitude lower than one cent, and RIR policies ere extremely
> liberal?
>
>
>
> It would be extremely easy to simply carry over practices that we have in
> IPv4 to IPv6. But because applications are incentivized to add application
> complexity in order to work properly on all networks, there is a risk that
> we might get stuck there, and never be able to elevate ourselves out of
> those practices. If that happens will keep suffering the problems caused by
> IP address scarcity even after scarcity is banished. That would be a bad
> outcome.
>
>
>
> Of course I may be wrong and a one-address-per-host model is the right
> choice. But I don't think we can tell at the moment. Over the years,
> network administrators that learn about IP (and application developers that
> write applications) on dual-stack networks with a mix of SLAAC and DHCPv6
> will be able to make better choices between these protocols than we can
> today.
>
>
>
> Cheers,
>
> Lorenzo
>
>
>
> On Fri, Jan 20, 2017 at 1:59 AM, Bernie Volz (volz) <[email-masked]>
> wrote:
>
> While I probably shouldn't send this as it is in the political and not
> technical space, I frankly am very disappointed in one company that, while
> trying to promote IPv6 usage, has also worked very hard to limit its use by
> NOT supporting a protocol developed by the IETF.
>
> I'm also surprised that organizations haven't pushed harder to get that
> company to implement the standards. I suspect though that is because IPv6
> is not yet "critical" for deployment. This provides the company an
> opportunity to push their agenda (whatever it may be).
>
> I will admit that being DHC WG co-chair, coauthor of the some of the
> standards, and also a vendor does bias me.
>
> - Bernie
>
>
>
> _______________________________________________
> Dhcpv6bis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcpv6bis
>
>

-- 

Now offering testing for SDN applications and controllers in our SDN switch
test bed. Learn more today http://bit.ly/SDN_IOLPR

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 19 Jan 2017 22:03:46 +0000

Hi Fred:

Is this with respect to https://www.ietf.org/mail-archive/web/v6ops/current/msg25366.html? If not, can you enlighten us?

And if is, not sure what’s actionable (i.e., what we you like to see changed/added to in 3315bis). We have removed most of the “requesting router” / “delegating router” language in the upcoming 07 (xml available in github - https://github.com/dhcwg/rfc3315bis/blob/master/rfc3315bis.xml) – what remains is mostly there to connect the dots with RFC 3633 and its terminology.

If you propose some specific changes / additions, we can review and discuss them.

-          Bernie

From: Templin, Fred L [mailto:[email-masked]]
Sent: Thursday, January 19, 2017 4:57 PM
To: Bernie Volz (volz) <[email-masked]>; [email-masked]' <[email-masked]>
Subject: RE: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem

Hi Bernie,

Thanks - Fred

From: Dhcpv6bis [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Thursday, January 19, 2017 1:51 PM
To: [email-masked]' <[email-masked]<mailto:[email-masked]>>
Subject: [Dhcpv6bis] FW: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem

-          Bernie

From: Bernie Volz (volz)

Hi Lorenzo:

-          Bernie

Bernie,

Cheers,
Lorenzo

- Bernie

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 19 Jan 2017 22:09:32 +0000

Hi Bernie,

Yes, the message you cited is the one I was referring to. But, I am not seeking any action
for rfc3315bis – as long as backward compatibility with RFC3633 is preserved, that is.

I have DHCPv6 PD working for mobile devices which, in my opinion, is a prime use case
for DHCPv6. My question was more along the lines of to what degree should we be
raising our voices on the v6ops list?

Thanks - Fred

From: Bernie Volz (volz) [mailto:[email-masked]]
Sent: Thursday, January 19, 2017 2:04 PM
To: Templin, Fred L <[email-masked]>; [email-masked]' <[email-masked]>
Subject: RE: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem

Hi Fred:

-          Bernie

From: Templin, Fred L [mailto:[email-masked]]
Sent: Thursday, January 19, 2017 4:57 PM
To: Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>>; [email-masked]' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem

Hi Bernie,

Thanks - Fred

-          Bernie

From: Bernie Volz (volz)

Hi Lorenzo:

-          Bernie

Bernie,

Cheers,
Lorenzo

- Bernie

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 19 Jan 2017 22:15:43 +0000

I’ll add an entry to the sheet about this to track it. I haven’t really thought about where this could go.

-          Bernie

From: Timothy Winters [mailto:[email-masked]]
Sent: Thursday, January 19, 2017 5:00 PM
To: Bernie Volz (volz) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Dhcpv6bis] FW: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem

Hi Bernie,

I've been following this thread, I think we may want to clearly document the ability to get multiple addresses.

~Tim

On Thu, Jan 19, 2017 at 4:50 PM, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:
FYI … Not sure you’ve been following this lengthy debate on the v6ops mailing list.

-          Bernie

From: Bernie Volz (volz)

Hi Lorenzo:

-          Bernie

From: Lorenzo Colitti [mailto:[email-masked]<mailto:[email-masked]>]

Bernie,

Cheers,
Lorenzo

- Bernie

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

--

Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 19 Jan 2017 22:23:28 +0000

The v6ops discussion on this thread has morphed far from what the original topic was (i.e., what to do about THAT document). It is now a broader discussion on SLAAC vs DHCPv6 …

And Fred has already sent one “Children, children” message (before I even chimed in) which I think was targeted to return the discussion to the original issue (about THAT document).

And the main issue for us at present is the SLAAC vs DHCPv6 IA_NA issue and not so much DHCPv6 PD. Though I fear that may be next given the draft-pioxfolks-6man-pio-exclusive-bit-01, IPv6 Router Advertisement Prefix Information Option Exclusive Bit, discussion. While this is for now focused on hosts, I do wonder how soon someone will suggest “hey, why not just this for routers too and we don’t need DHCPv6 PD”!

Things are likely to get more complex … not less for a while.

-          Bernie

From: Templin, Fred L [mailto:[email-masked]]
Sent: Thursday, January 19, 2017 5:10 PM
To: Bernie Volz (volz) <[email-masked]>; [email-masked]' <[email-masked]>
Subject: RE: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem

Hi Bernie,

Thanks - Fred

From: Bernie Volz (volz) [mailto:[email-masked]]
Sent: Thursday, January 19, 2017 2:04 PM
To: Templin, Fred L <[email-masked]<mailto:[email-masked]>>; [email-masked]' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem

Hi Fred:

-          Bernie

Hi Bernie,

Thanks - Fred

-          Bernie

From: Bernie Volz (volz)

Hi Lorenzo:

-          Bernie

Bernie,

Cheers,
Lorenzo

- Bernie