IPv6 Site Renumbering Gap Analysis
draft-ietf-6renum-gap-analysis-08

[Ballot comment]
Former DISCUSS text:

This document seems unclear as to the exact scenario it is addressing.  If it is essentially addressing the scenario described in RFC 4192, the document needs to be reviewed to make sure that the gaps identified are real gaps that could actually happen in an RFC 4192 scenario.  If that is not the scenario that this document is intended to address, the document needs to clarify what scenario it does intend to address.

I've mentioned in the comments a number of cases where the document doesn't appear to be referring to use cases that could actually happen in an RFC 4192 scenario; I'm concerned that as it is written, it will lead readers to misunderstand how renumbering ought to work, and will actually lead them to do things that make their lives worse during a renumbering event.  At the very least, I think the document needs to strongly state that it presumes the reader already has a clear understanding of RFC 4192, because if they read this document without reading 4192, I really think they will get the wrong impression.

I think the document is going in a good direction, and I would support publication if this problem can be addressed.

Suggestion in section 2:
OLD:
  o Hosts that are configured through DHCPv6 [RFC3315] can reconfigure
      addresses by starting RENEW actions when the current addresses'
      lease time are expired or they receive the reconfiguration
      messages initiated by the DHCPv6 servers.
NEW:
  o Hosts that are configured through DHCPv6 [RFC3315] obtain new
      addresses through the renewal process or when they receive the reconfiguration
      messages initiated by the DHCPv6 servers.

The reason for the proposed change is that renewal doesn't happen at expiry time, and addresses aren't changed through the Renew process.  The current text is less specific, but probably specific enough for the context, and I suspect more helpful to the reader at this point in the document.

In section 4.1, I'm really skeptical that this paragraph bears any relationship to reality for any enterprise setting larger than a SOHO configuration:

  Usually, the new short prefix(es) comes down from the operator(s) and
  is received by DHCPv6 servers or routers inside the enterprise
  networks (or through off-line human communication). The short
  prefix(es) could be automatically delegated through DHCPv6-PD. Then
  the downlink DHCPv6 servers or routers can begin advertising the
  longer prefixes to the subnets.

Are you actually seeing this in practice?  I would expect an enterprise-level site to have a negotiated prefix which is statically configured and controlled via contract, not via protocol.  This scenario certainly could happen in a home environment or a home office environment, but this document doesn't seem to be addressing that use case.  You do mention off-line communication in parentheses, but I really think that should be what you lead in with—it doesn't make sense to me otherwise.  I am of course willing to be persuaded on this question—I think it's a bit speculative at the moment since I don't know of a lot of enterprises that do production IPv6 internally yet.  Did you ask the Google guys what they do?

In 4.2:
  When subnet routers receive the longer prefixes, they can directly
  assign them to the hosts.  Host address configuration, rather than
  routers, is the primary concern for prefix assignment which is
  described in the following section 5.1.

What does it mean for a router to assign a prefix to a host?  Do you mean "advertise a prefix on a link to which hosts are connected?"

In 5.1:
  Another limitation of DHCPv6 reconfiguration is that it only allows
  the messages to be delivered to unicast addresses. So if we want to
  use it for bulk renumbering, stateless DHCPv6 reconfiguration with
  multicast may be needed. However, this may involve protocol
  modification.

This is not accurate.  The DHCPv6 server has a complete list of all clients on any given link.  It can issue unicast reconfigure messages to each client, if desired.  Multicast DHCPv6 reconfigure is not an option, because it's too easy to use it for a DoS attack.

I notice also that you don't mention the 'A' bit in router advertisements.  I think this bit also affects the behavior of various stacks; I'm not sure, but I think it probably should be discussed.

Section 6.1 talks about DDNS as a way to update IP addresses on names during a renumbering event.  I'm not at all clear on what the use model for this would be.  If we're renumbering servers, then certainly you could configure each server with its own key to use for doing updates, so that it could poke its new SLAAC- or DHCPv6-derived address into the DNS. I'm not sure this is a good _idea_, but it's eminently doable.

The document seems to mention RFC 4704 in passing, without citing it.  Possibly the authors aren't actually familiar with RFC 4074, but just thought that some commercial servers might have custom solutions to this problem?  I think RFC 4074 entirely addresses this problem, at least for hosts that can be numbered using DHCPv6.

The combination of RFC4074 and server-oriented DDNS could probably address most of the problems one might care about with respect to the problem 6.1 is trying to address.  Of course, there is still a gap here, since servers have to somehow notice that their address has changed and trigger the DDNS update.

The document also mentions A6 records here, which are deprecated (RFC 6563), and therefore ought not to be mentioned.

In 6.2:
  (Addresses of DHCPv6 servers do not  need to be updated. They are dynamically
    discovered using DHCPv6 relevant multicast addresses.)

While this could be true in principle, it isn't true in practice, because most relay agents have the option of being configured with DHCPv6 server addresses rather than sending to a multicast address, and I think it's more common to do unicast than multicast for this step. So the document shouldn't assume that this is a solved problem. Even in the case of multicast, it's necessary for multicast routing to be configured and working in order for DHCP messages to find their way to servers. In theory a renumbering event shouldn't break multicast routing, but in practice it might.

  The DNS server addresses for hosts could be configured by DHCPv6. In
  stateless DHCPv6 mode [RFC3736], [RFC4242] allows the server to
  specify valid time for the DNS configuration. But in stateful DHCPv6,
  current protocols could not indicate hosts the valid time of DNS
  configuration. If the DNS server has been renumbered, and the DHCP
  lease time has not expired yet, then the hosts would still use the
  old DNS server address(es). It might be better that the hosts could
  renew the DHCP DNS configuration before the lease time, especially
  there might be some extreme situations that the lease time need to be
  long. In this case how the DHCP server could learn the proper DNS
  configuration valid time is also an issue.

There are a bunch of problems with this. First, the stateful DHCP T1 and T2 times are effectively equivalent to the stateless DHCP Information Refresh Timer (DHCPv6 doesn't talk about leases or lease times, so this term should not be used; rather, addresses have lifetimes, and IAs have T1 and T2 timers that indicate to the client when to renew or rebind, respectively). So there is no need for an additional timer in stateful DHCPv6; indeed, it doesn't make sense to add one just for renumbering. How would you know what value to set it to? Why wouldn't you just set T1 to that value?

Next problem: in a typical renumbering scenario, the old and new prefixes are both valid. The old prefix is deprecated, but still works. So the DNS server is still reachable at the old address: there is no interruption of service. Deprecated addresses and prefixes decay gracefully, so that by the time they are gone, everybody has renumbered. Hence, the scenario being described here should never happen unless someone unconfigures the deprecated address on the DNS server before all the hosts have stopped using it. That would be an administrative error.

Section 6.3 appears to be a pair of solutions, not a gap. It is described as a gap, in the sense that the solutions are lacking, but it's not describing the actual gap. This seems to be putting the cart before the horse. The right thing to do is to identify the gap that this solution would fill, rather than describing the absence of these solutions as a gap.

I think the gap you are talking about is that there isn't a way to trigger configuration updates for all the subsystems on a server, and all the external databases that refer to that server, on the basis of a change to the server's IP address. I am not positive that you need to change the way you are approaching this, because I think the solutions you are talking about are interesting, but this section really doesn't feel like it's a gap analysis as written, so starting from what the gap is and talking about how it could be addressed might help.

More examples in this section might help: I think the tunnel endpoint example is a really good one to use. There are probably some other examples that would be good here—e.g., I have static IP addresses configured in my nginx configuration. This isn't really the gap—I ought to just put domain names in. But unless the tunnel endpoint or nginx notices that the addresses returned for that domain name have changed, it will keep blindly using the old address until something triggers it to do a refresh or a restart. You mention this in 5.2, but it should be mentioned here as well, since as far as I know most services do not actually refresh DNS information until they are triggered somehow to do so.

In section 7.2, what do you mean by "no mechanisms?" RFC 4192 talks about how to address this issue, if I understand the issue correctly.  Or is the gap you are talking about the lack of a way to set all the TTLs for a zone to no more than a particular value?

Section 10.2 mentions the A6 record again.  I don't think this is helpful, because it died for a reason.  I think you should leave this out.  Also, I think you need to lead in with the authority problem—my first read of this section really puzzled me, because it seemed to be talking about a problem that is easy to solve, and it was only when I saw the acknowledgement in section 13 that I went and read the chown draft and then reread section 10.2 and understood what the gap was that was being documented.

It looks like 10.3, second bullet, is talking about the problem I mentioned in 6.3 with services not refreshing DNS information.  I think the techniques you talk about in 6.3 can address this problem, so I don't think it's an unaddressable gap.  If this isn't the gap you are talking about, a bit more exposition might be required...

[Ballot discuss]
My initial DISCUSS was:
In section 7, you miss a discussion regarding the host/router unique id in the NMS applications
Let's start with syslog, SNMP notification, and IPFIX. For all of these protocols, the host or router id is the UDP message source IP address. Sometimes this matches the device loopback IP address: indeed, we can force the loopback IP address as the source IP address for IPFIX/syslog message/SNMP notifications.
If the source IP address is changed (whether it matches the loopback is irrelevant), the syslogd, trapd, or IPFIX collector will consider that a new device appeared in the network. This is a problem.
I don't want to say that the IP address mapping must be sent in band (i.e. in SNMP, syslog, or IPFIX), maybe updating DNS is sufficient, maybe querying a UUID is the solution, or maybe the solution depends on the protocol (sending the MAC or a UUID in IPFIX would help, as Options Template Record). So maybe there are different solutions for the different protocols.
A discussion/some text is required concerning the host and router unique IDs in NMS applications: these applications should be aware of the IP address mapping.
This might lead to some extra bullet point in the section 9.4

You have correctly addressed one part of the DISCUSS, in section 7.1. Renumbering Notification, with "logs collected through syslog, SNMP notification, IPFIX, etc.", but you miss a second part of it: the host/router unique id in the NMS applications. So any NMS topology map, based on network discovery, needs to be aware of the host/router unique id mappings. This new text should be section 7.2, or even better in a new section.

[Ballot comment]
Suggestion in section 2:
OLD:
  o Hosts that are configured through DHCPv6 [RFC3315] can reconfigure
      addresses by starting RENEW actions when the current addresses'
      lease time are expired or they receive the reconfiguration
      messages initiated by the DHCPv6 servers.
NEW:
  o Hosts that are configured through DHCPv6 [RFC3315] obtain new
      addresses through the renewal process or when they receive the reconfiguration
      messages initiated by the DHCPv6 servers.

The reason for the proposed change is that renewal doesn't happen at expiry time, and addresses aren't changed through the Renew process.  The current text is less specific, but probably specific enough for the context, and I suspect more helpful to the reader at this point in the document.

In section 4.1, I'm really skeptical that this paragraph bears any relationship to reality for any enterprise setting larger than a SOHO configuration:

  Usually, the new short prefix(es) comes down from the operator(s) and
  is received by DHCPv6 servers or routers inside the enterprise
  networks (or through off-line human communication). The short
  prefix(es) could be automatically delegated through DHCPv6-PD. Then
  the downlink DHCPv6 servers or routers can begin advertising the
  longer prefixes to the subnets.

Are you actually seeing this in practice?  I would expect an enterprise-level site to have a negotiated prefix which is statically configured and controlled via contract, not via protocol.  This scenario certainly could happen in a home environment or a home office environment, but this document doesn't seem to be addressing that use case.  You do mention off-line communication in parentheses, but I really think that should be what you lead in with—it doesn't make sense to me otherwise.  I am of course willing to be persuaded on this question—I think it's a bit speculative at the moment since I don't know of a lot of enterprises that do production IPv6 internally yet.  Did you ask the Google guys what they do?

In 4.2:
  When subnet routers receive the longer prefixes, they can directly
  assign them to the hosts.  Host address configuration, rather than
  routers, is the primary concern for prefix assignment which is
  described in the following section 5.1.

What does it mean for a router to assign a prefix to a host?  Do you mean "advertise a prefix on a link to which hosts are connected?"

In 5.1:
  Another limitation of DHCPv6 reconfiguration is that it only allows
  the messages to be delivered to unicast addresses. So if we want to
  use it for bulk renumbering, stateless DHCPv6 reconfiguration with
  multicast may be needed. However, this may involve protocol
  modification.

This is not accurate.  The DHCPv6 server has a complete list of all clients on any given link.  It can issue unicast reconfigure messages to each client, if desired.  Multicast DHCPv6 reconfigure is not an option, because it's too easy to use it for a DoS attack.

I notice also that you don't mention the 'A' bit in router advertisements.  I think this bit also affects the behavior of various stacks; I'm not sure, but I think it probably should be discussed.

Section 6.1 talks about DDNS as a way to update IP addresses on names during a renumbering event.  I'm not at all clear on what the use model for this would be.  If we're renumbering servers, then certainly you could configure each server with its own key to use for doing updates, so that it could poke its new SLAAC- or DHCPv6-derived address into the DNS. I'm not sure this is a good _idea_, but it's eminently doable.

The document seems to mention RFC 4704 in passing, without citing it.  Possibly the authors aren't actually familiar with RFC 4074, but just thought that some commercial servers might have custom solutions to this problem?  I think RFC 4074 entirely addresses this problem, at least for hosts that can be numbered using DHCPv6.

The combination of RFC4074 and server-oriented DDNS could probably address most of the problems one might care about with respect to the problem 6.1 is trying to address.  Of course, there is still a gap here, since servers have to somehow notice that their address has changed and trigger the DDNS update.

The document also mentions A6 records here, which are deprecated (RFC 6563), and therefore ought not to be mentioned.

In 6.2:
  (Addresses of DHCPv6 servers do not  need to be updated. They are dynamically
    discovered using DHCPv6 relevant multicast addresses.)

While this could be true in principle, it isn't true in practice, because most relay agents have the option of being configured with DHCPv6 server addresses rather than sending to a multicast address, and I think it's more common to do unicast than multicast for this step. So the document shouldn't assume that this is a solved problem. Even in the case of multicast, it's necessary for multicast routing to be configured and working in order for DHCP messages to find their way to servers. In theory a renumbering event shouldn't break multicast routing, but in practice it might.

  The DNS server addresses for hosts could be configured by DHCPv6. In
  stateless DHCPv6 mode [RFC3736], [RFC4242] allows the server to
  specify valid time for the DNS configuration. But in stateful DHCPv6,
  current protocols could not indicate hosts the valid time of DNS
  configuration. If the DNS server has been renumbered, and the DHCP
  lease time has not expired yet, then the hosts would still use the
  old DNS server address(es). It might be better that the hosts could
  renew the DHCP DNS configuration before the lease time, especially
  there might be some extreme situations that the lease time need to be
  long. In this case how the DHCP server could learn the proper DNS
  configuration valid time is also an issue.

There are a bunch of problems with this. First, the stateful DHCP T1 and T2 times are effectively equivalent to the stateless DHCP Information Refresh Timer (DHCPv6 doesn't talk about leases or lease times, so this term should not be used; rather, addresses have lifetimes, and IAs have T1 and T2 timers that indicate to the client when to renew or rebind, respectively). So there is no need for an additional timer in stateful DHCPv6; indeed, it doesn't make sense to add one just for renumbering. How would you know what value to set it to? Why wouldn't you just set T1 to that value?

Next problem: in a typical renumbering scenario, the old and new prefixes are both valid. The old prefix is deprecated, but still works. So the DNS server is still reachable at the old address: there is no interruption of service. Deprecated addresses and prefixes decay gracefully, so that by the time they are gone, everybody has renumbered. Hence, the scenario being described here should never happen unless someone unconfigures the deprecated address on the DNS server before all the hosts have stopped using it. That would be an administrative error.

Section 6.3 appears to be a pair of solutions, not a gap. It is described as a gap, in the sense that the solutions are lacking, but it's not describing the actual gap. This seems to be putting the cart before the horse. The right thing to do is to identify the gap that this solution would fill, rather than describing the absence of these solutions as a gap.

I think the gap you are talking about is that there isn't a way to trigger configuration updates for all the subsystems on a server, and all the external databases that refer to that server, on the basis of a change to the server's IP address. I am not positive that you need to change the way you are approaching this, because I think the solutions you are talking about are interesting, but this section really doesn't feel like it's a gap analysis as written, so starting from what the gap is and talking about how it could be addressed might help.

More examples in this section might help: I think the tunnel endpoint example is a really good one to use. There are probably some other examples that would be good here—e.g., I have static IP addresses configured in my nginx configuration. This isn't really the gap—I ought to just put domain names in. But unless the tunnel endpoint or nginx notices that the addresses returned for that domain name have changed, it will keep blindly using the old address until something triggers it to do a refresh or a restart. You mention this in 5.2, but it should be mentioned here as well, since as far as I know most services do not actually refresh DNS information until they are triggered somehow to do so.

In section 7.2, what do you mean by "no mechanisms?" RFC 4192 talks about how to address this issue, if I understand the issue correctly.  Or is the gap you are talking about the lack of a way to set all the TTLs for a zone to no more than a particular value?

Section 10.2 mentions the A6 record again.  I don't think this is helpful, because it died for a reason.  I think you should leave this out.  Also, I think you need to lead in with the authority problem—my first read of this section really puzzled me, because it seemed to be talking about a problem that is easy to solve, and it was only when I saw the acknowledgement in section 13 that I went and read the chown draft and then reread section 10.2 and understood what the gap was that was being documented.

It looks like 10.3, second bullet, is talking about the problem I mentioned in 6.3 with services not refreshing DNS information.  I think the techniques you talk about in 6.3 can address this problem, so I don't think it's an unaddressable gap.  If this isn't the gap you are talking about, a bit more exposition might be required...

[Ballot discuss]
This document seems unclear as to the exact scenario it is addressing.  If it is essentially addressing the scenario described in RFC 4192, the document needs to be reviewed to make sure that the gaps identified are real gaps that could actually happen in an RFC 4192 scenario.  If that is not the scenario that this document is intended to address, the document needs to clarify what scenario it does intend to address.

I've mentioned in the comments a number of cases where the document doesn't appear to be referring to use cases that could actually happen in an RFC 4192 scenario; I'm concerned that as it is written, it will lead readers to misunderstand how renumbering ought to work, and will actually lead them to do things that make their lives worse during a renumbering event.  At the very least, I think the document needs to strongly state that it presumes the reader already has a clear understanding of RFC 4192, because if they read this document without reading 4192, I really think they will get the wrong impression.

I think the document is going in a good direction, and I would support publication if this problem can be addressed.

[Ballot comment]
Suggestion in section 2:
OLD:
  o Hosts that are configured through DHCPv6 [RFC3315] can reconfigure
      addresses by starting RENEW actions when the current addresses'
      lease time are expired or they receive the reconfiguration
      messages initiated by the DHCPv6 servers.
NEW:
  o Hosts that are configured through DHCPv6 [RFC3315] obtain new
      addresses through the renewal process or when they receive the reconfiguration
      messages initiated by the DHCPv6 servers.

The reason for the proposed change is that renewal doesn't happen at expiry time, and addresses aren't changed through the Renew process.  The current text is less specific, but probably specific enough for the context, and I suspect more helpful to the reader at this point in the document.

In section 4.1, I'm really skeptical that this paragraph bears any relationship to reality for any enterprise setting larger than a SOHO configuration:

  Usually, the new short prefix(es) comes down from the operator(s) and
  is received by DHCPv6 servers or routers inside the enterprise
  networks (or through off-line human communication). The short
  prefix(es) could be automatically delegated through DHCPv6-PD. Then
  the downlink DHCPv6 servers or routers can begin advertising the
  longer prefixes to the subnets.

Are you actually seeing this in practice?  I would expect an enterprise-level site to have a negotiated prefix which is statically configured and controlled via contract, not via protocol.  This scenario certainly could happen in a home environment or a home office environment, but this document doesn't seem to be addressing that use case.  You do mention off-line communication in parentheses, but I really think that should be what you lead in with—it doesn't make sense to me otherwise.  I am of course willing to be persuaded on this question—I think it's a bit speculative at the moment since I don't know of a lot of enterprises that do production IPv6 internally yet.  Did you ask the Google guys what they do?

In 4.2:
  When subnet routers receive the longer prefixes, they can directly
  assign them to the hosts.  Host address configuration, rather than
  routers, is the primary concern for prefix assignment which is
  described in the following section 5.1.

What does it mean for a router to assign a prefix to a host?  Do you mean "advertise a prefix on a link to which hosts are connected?"

In 5.1:
  Another limitation of DHCPv6 reconfiguration is that it only allows
  the messages to be delivered to unicast addresses. So if we want to
  use it for bulk renumbering, stateless DHCPv6 reconfiguration with
  multicast may be needed. However, this may involve protocol
  modification.

This is not accurate.  The DHCPv6 server has a complete list of all clients on any given link.  It can issue unicast reconfigure messages to each client, if desired.  Multicast DHCPv6 reconfigure is not an option, because it's too easy to use it for a DoS attack.

I notice also that you don't mention the 'A' bit in router advertisements.  I think this bit also affects the behavior of various stacks; I'm not sure, but I think it probably should be discussed.

Section 6.1 talks about DDNS as a way to update IP addresses on names during a renumbering event.  I'm not at all clear on what the use model for this would be.  If we're renumbering servers, then certainly you could configure each server with its own key to use for doing updates, so that it could poke its new SLAAC- or DHCPv6-derived address into the DNS.  I'm not sure this is a good _idea_, but it's eminently doable.

As for non-server hosts, have the authors read RFC 4704?  For hosts that are numbered using DHCP, RFC 4704 addresses this problem.

The document also mentions A6 records here, which are deprecated (RFC 6563), and therefore ought not to be mentioned.

In 6.2:
  (Addresses of DHCPv6 servers do not  need to be updated. They are dynamically
    discovered using DHCPv6 relevant multicast addresses.)

While this could be true in principle, it isn't true in practice, because most relay agents have the option of being configured with DHCPv6 server addresses rather than sending to a multicast address, and I think it's more common to do unicast than multicast for this step. So the document shouldn't assume that this is a solved problem. Even in the case of multicast, it's necessary for multicast routing to be configured and working in order for DHCP messages to find their way to servers. In theory a renumbering event shouldn't break multicast routing, but in practice it might.

  The DNS server addresses for hosts could be configured by DHCPv6. In
  stateless DHCPv6 mode [RFC3736], [RFC4242] allows the server to
  specify valid time for the DNS configuration. But in stateful DHCPv6,
  current protocols could not indicate hosts the valid time of DNS
  configuration. If the DNS server has been renumbered, and the DHCP
  lease time has not expired yet, then the hosts would still use the
  old DNS server address(es). It might be better that the hosts could
  renew the DHCP DNS configuration before the lease time, especially
  there might be some extreme situations that the lease time need to be
  long. In this case how the DHCP server could learn the proper DNS
  configuration valid time is also an issue.

There are a bunch of problems with this. First, the stateful DHCP T1 and T2 times are effectively equivalent to the stateless DHCP Information Refresh Timer (DHCPv6 doesn't talk about leases or lease times, so this term should not be used; rather, addresses have lifetimes, and IAs have T1 and T2 timers that indicate to the client when to renew or rebind, respectively). So there is no need for an additional timer in stateful DHCPv6; indeed, it doesn't make sense to add one just for renumbering. How would you know what value to set it to? Why wouldn't you just set T1 to that value?

Next problem: in a typical renumbering scenario, the old and new prefixes are both valid. The old prefix is deprecated, but still works. So the DNS server is still reachable at the old address: there is no interruption of service. Deprecated addresses and prefixes decay gracefully, so that by the time they are gone, everybody has renumbered. Hence, the scenario being described here should never happen unless someone unconfigures the deprecated address on the DNS server before all the hosts have stopped using it. That would be an administrative error.

Section 6.3 appears to be a pair of solutions, not a gap. It is described as a gap, in the sense that the solutions are lacking, but it's not describing the actual gap. This seems to be putting the cart before the horse. The right thing to do is to identify the gap that this solution would fill, rather than describing the absence of these solutions as a gap.

I think you can probably get a gap out of these solutions pretty easily. I think the gap you are talking about is that there isn't a way to trigger configuration updates for all the subsystems on a server, and all the external databases that refer to that server, on the basis of a change to the server's IP address. I am not positive that you need to change the way you are approaching this, because I think the solutions you are talking about are interesting, but this section really doesn't feel like it's a gap analysis as written, so starting from what the gap is and talking about how it could be addressed might help.

More examples in this section might help: I think the tunnel endpoint example is a really good one to use. There are probably some other examples that would be good here—e.g., I have static IP addresses configured in my nginx configuration. This isn't really the gap—I ought to just put domain names in. But unless the tunnel endpoint or nginx notices that the addresses returned for that domain name have changed, it will keep blindly using the old address until something triggers it to do a refresh or a restart. You mention this in 5.2, but it should be mentioned here as well, since as far as I know most services do not actually refresh DNS information until they are triggered somehow to do so.

In section 7.2, what do you mean by "no mechanisms?" RFC 4192 talks about how to address this issue, if I understand the issue correctly.  Or is the gap you are talking about the lack of a way to set all the TTLs for a zone to no more than a particular value?

Section 10.2 mentions the A6 record again.  I don't think this is helpful, because it died for a reason.  I think you should leave this out.  Also, I think you need to lead in with the authority problem—my first read of this section really puzzled me, because it seemed to be talking about a problem that is easy to solve, and it was only when I saw the acknowledgement in section 13 that I went and read the chown draft and then reread section 10.2 and understood what the gap was that was being documented.

It looks like 10.3, second bullet, is talking about the problem I mentioned in 6.3 with services not refreshing DNS information.  I think the techniques you talk about in 6.3 can address this problem, so I don't think it's an unaddressable gap.  If this isn't the gap you are talking about, a bit more exposition might be required...

[Ballot discuss]
This document seems unclear as to the exact scenario it is addressing.  If it is essentially addressing the scenario described in RFC 4192, the document needs to be reviewed to make sure that the gaps identified are real gaps that could actually happen in an RFC 4192 scenario.  If that is not the scenario that this document is intended to address, the document needs to clarify what scenario it does intend to address.

I've mentioned in the comments a number of cases where the document doesn't appear to be referring to use cases that could actually happen in an RFC 4192 scenario; I'm concerned that as it is written, it will lead readers to misunderstand how renumbering ought to work, and will actually lead them to do things that make their lives worse during a renumbering event.  At the very least, I think the document needs to strongly advice readers to familiarize themselves with RFC 4192 before proceeding, because if they read this document without reading 4192, I really think they will get the wrong impression.

I think the document is going in a good direction, and I would support publication if this problem can be addressed.

[Ballot comment]
Suggestion:
OLD:
  o Hosts that are configured through DHCPv6 [RFC3315] can reconfigure
      addresses by starting RENEW actions when the current addresses'
      lease time are expired or they receive the reconfiguration
      messages initiated by the DHCPv6 servers.
NEW:
  o Hosts that are configured through DHCPv6 [RFC3315] obtain new
      addresses through the renewal process or when they receive the reconfiguration
      messages initiated by the DHCPv6 servers.

The reason for the proposed change is that renewal doesn't happen at expiry time, and addresses aren't changed through the Renew process.  The current text is less specific, but probably specific enough for the context, and I suspect more helpful to the reader at this point in the document.

I'm really skeptical that this paragraph bears any relationship to reality for any enterprise setting larger than a SOHO configuration:

  Usually, the new short prefix(es) comes down from the operator(s) and
  is received by DHCPv6 servers or routers inside the enterprise
  networks (or through off-line human communication). The short
  prefix(es) could be automatically delegated through DHCPv6-PD. Then
  the downlink DHCPv6 servers or routers can begin advertising the
  longer prefixes to the subnets.

Are you actually seeing this in practice?  I would expect an enterprise-level site to have a negotiated prefix which is statically configured and controlled via contract, not via protocol.  This scenario certainly could happen in a home environment or a home office environment, but this document doesn't seem to be addressing that use case.  You do mention off-line communication in parentheses, but I really think that should be what you lead in with—it doesn't make sense to me otherwise.  I am of course willing to be persuaded on this question—I think it's a bit speculative at the moment since I don't know of a lot of enterprises that do production IPv6 internally yet.  Did you ask the Google guys what they do?

  When subnet routers receive the longer prefixes, they can directly
  assign them to the hosts.  Host address configuration, rather than
  routers, is the primary concern for prefix assignment which is
  described in the following section 5.1.

What does it mean for a router to assign a prefix to a host?  Do you mean "advertise a prefix on a link to which hosts are connected?"

  Another limitation of DHCPv6 reconfiguration is that it only allows
  the messages to be delivered to unicast addresses. So if we want to
  use it for bulk renumbering, stateless DHCPv6 reconfiguration with
  multicast may be needed. However, this may involve protocol
  modification.

This is not accurate.  The DHCPv6 server has a complete list of all clients on any given link.  It can issue unicast reconfigure messages to each client, if desired.  Multicast DHCPv6 reconfigure is not an option, because it's too easy to use it for a DoS attack.

I notice also that you don't mention the 'A' bit in router advertisements.  I think this bit also affects the behavior of various stacks; I'm not sure, but I think it probably should be discussed.

Section 6.1 talks about DDNS as a way to update IP addresses on names during a renumbering event.  I'm not at all clear on what the use model for this would be.  If we're renumbering servers, then certainly you could configure each server with its own key to use for doing updates, so that it could poke its new SLAAC- or DHCPv6-derived address into the DNS.  I'm not sure this is a good _idea_, but it's eminently doable.

As for non-server hosts, have the authors read RFC 4704?  For hosts that are numbered using DHCP, RFC 4704 addresses this problem.

It would certainly be helpful to have support for automatic renumbering on the DNS server, or to use the DHCP server to do renumbering, in cases where this makes sense, but I think that in practice either you have an IPAM system that's going to do all the poking around, or you are using DHCPv6 for non-server hosts and DDNS for server hosts, or the sysadmin is going in and manually changing settings.  I hate this last solution, but if it's ten servers, that's not the end of the world.  It would not work in a cloud hosting environment or anything like that, but I don't get the impression that that is the use case this document is addressing.

The document also mentions A6 records, which are deprecated (RFC 6563), and therefore ought not to be mentioned.

(Addresses of DHCPv6 servers do not  need to be updated. They are dynamically discovered using DHCPv6 relevant multicast addresses.)

While this could be true in principle, it isn't true in practice, because most relay agents have the option of being configured with DHCPv6 server addresses rather than sending to a multicast address, and I think it's more common to do unicast than multicast for this step.  So the document shouldn't assume that this is a solved problem.  Even in the case of multicast, it's necessary for multicast routing to be configured and working in order for DHCP messages to find their way to servers.  In theory a renumbering event shouldn't break multicast routing, but in practice it might.

  The DNS server addresses for hosts could be configured by DHCPv6. In
  stateless DHCPv6 mode [RFC3736], [RFC4242] allows the server to
  specify valid time for the DNS configuration. But in stateful DHCPv6,
  current protocols could not indicate hosts the valid time of DNS
  configuration. If the DNS server has been renumbered, and the DHCP
  lease time has not expired yet, then the hosts would still use the
  old DNS server address(es). It might be better that the hosts could
  renew the DHCP DNS configuration before the lease time, especially
  there might be some extreme situations that the lease time need to be
  long. In this case how the DHCP server could learn the proper DNS
  configuration valid time is also an issue.

There are a bunch of problems with this.  First, the stateful DHCP T1 and T2 times are effectively equivalent to the stateless DHCP Information Refresh Timer (DHCPv6 doesn't talk about leases or lease times, so this term should not be used; rather, addresses have lifetimes, and IAs have T1 and T2 timers that indicate to the client when to renew or rebind, respectively).  So there is no need for an additional timer in stateful DHCPv6; indeed, it doesn't make sense to add one just for renumbering.  How would you know what value to set it to?  Why wouldn't you just set T1 to that value?

Next problem: in a typical renumbering scenario, the old and new prefixes are both valid.  The old prefix is deprecated, but still works.  So the DNS server is still reachable at the old address: there is no interruption of service.  Deprecated addresses and prefixes decay gracefully, so that by the time they are gone, everybody has renumbered.  Hence, the scenario being described here should never happen unless someone unconfigures the deprecated address on the DNS server before all the hosts have stopped using it.  That would be an administrative error.

Section 6.3 appears to be a pair of solutions, not a gap.  It is described as a gap, in the sense that the solutions are lacking, but it's not describing the actual gap.  This seems to be putting the cart before the horse.  The right thing to do is to identify the gap that this solution would fill, rather than describing the absence of these solutions as a gap.

I think you can probably get a gap out of these solutions pretty easily. I think the gap you are talking about is that there isn't a way to trigger configuration updates for all the subsystems on a server, and all the external databases that refer to that server, on the basis of a change to the server's IP address.  I am not positive that you need to change the way you are approaching this, because I think the solutions you are talking about are interesting, but this section really doesn't feel like it's a gap analysis as written, so starting from what the gap is and talking about how it could be addressed might help.

More examples in this section might help: I think the tunnel endpoint example is a really good one to use.  There are probably some other examples that would be good here—e.g., I have static IP addresses configured in my nginx configuration.  This isn't really the gap—I ought to just put domain names in.  But unless the tunnel endpoint or nginx notices that the addresses returned for that domain name have changed, it will keep blindly using the old address until something triggers it to do a refresh or a restart.  You mention this in 5.2, but it should be mentioned here as well, since as far as I know most services do not actually refresh DNS information until they are triggered somehow to do so.

In section 7.2, what do you mean by "no mechanisms?"  There are mechanisms—if you know a renumbering event is coming up, you probably ought to shorten your TTLs.  This won't work if you have no advance notice of the renumbering event, but the document _seems_ to be talking about orderly renumbering.

If you are doing an orderly renumbering, where the old prefix is deprecated and the new prefix is added, then your TTL may be longer than the time to the deprecation of the old prefix.  This should be avoided—your SLA with the ISP should state a notice period for renumbering that is longer than your TTL, or to put it the other way, your TTL should be shorter than the notice period.  RFC 4192 Section 2.2 talks about this at length, so I presume the authors of this document are familiar with the process.

Is the gap you are talking about the lack of a way to set all the TTLs for a site to no more than a particular value?  If so, that is not clear here.  Or is it the lack of a way to update the names, first adding the new addresses, and later removing the old addresses?  Again, if that is what is intended, it should be made clear.

Section 10.2 mentions the A6 record again.  I don't think this is helpful, because it died for a reason.  I think you should leave this out.  Also, I think you need to lead in with the authority problem—my first read of this section really puzzled me, because it seemed to be talking about a problem that is easy to solve, and it was only when I saw the acknowledgement in section 13 that I went and read the chown draft and then reread section 10.2 and understood what the gap was that was being documented.

It looks like 10.3, second bullet, is talking about the problem I mentioned in 6.3 with services not refreshing DNS information.  I think the techniques you talk about in 6.3 can address this problem, so I don't think it's an unaddressable gap.

[Ballot discuss]
I don't think this document is ready for publication yet.  I've mentioned in the comments a number of cases where the document doesn't appear to be referring to use cases that could actually happen; I'm concerned that as it is written, it will lead readers to misunderstand how renumbering ought to work, and will actually lead them to do things that make their lives worse during a renumbering event.

At the very least, I think that this document needs to strongly emphasize the need for readers to familiarize themselves with RFC 4192 before proceeding.  I've included a bunch of comments that I hope will help to address some of the issues that I'm talking about, if the authors agree.

The fundamental concern in this DISCUSS is that the document seems unclear as to the exact scenario it is addressing.  If it is essentially addressing the scenario described in RFC 4192, the document needs to be reviewed to make sure that the gaps identified are real gaps that could actually happen in an RFC 4192 scenario.  If that is not the scenario that this document is intended to address, the document needs to clarify what scenario it does intend to address.

I think the document is going in a good direction, and I would support publication if this problem can be addressed.

[Ballot comment]
Suggestion:
OLD:
  o Hosts that are configured through DHCPv6 [RFC3315] can reconfigure
      addresses by starting RENEW actions when the current addresses'
      lease time are expired or they receive the reconfiguration
      messages initiated by the DHCPv6 servers.
NEW:
  o Hosts that are configured through DHCPv6 [RFC3315] obtain new
      addresses through the renewal process or when they receive the reconfiguration
      messages initiated by the DHCPv6 servers.

The reason for the proposed change is that renewal doesn't happen at expiry time, and addresses aren't changed through the Renew process.  The current text is less specific, but probably specific enough for the context, and I suspect more helpful to the reader at this point in the document.

I'm really skeptical that this paragraph bears any relationship to reality for any enterprise setting larger than a SOHO configuration:

  Usually, the new short prefix(es) comes down from the operator(s) and
  is received by DHCPv6 servers or routers inside the enterprise
  networks (or through off-line human communication). The short
  prefix(es) could be automatically delegated through DHCPv6-PD. Then
  the downlink DHCPv6 servers or routers can begin advertising the
  longer prefixes to the subnets.

Are you actually seeing this in practice?  I would expect an enterprise-level site to have a negotiated prefix which is statically configured and controlled via contract, not via protocol.  This scenario certainly could happen in a home environment or a home office environment, but this document doesn't seem to be addressing that use case.  You do mention off-line communication in parentheses, but I really think that should be what you lead in with—it doesn't make sense to me otherwise.  I am of course willing to be persuaded on this question—I think it's a bit speculative at the moment since I don't know of a lot of enterprises that do production IPv6 internally yet.  Did you ask the Google guys what they do?

  When subnet routers receive the longer prefixes, they can directly
  assign them to the hosts.  Host address configuration, rather than
  routers, is the primary concern for prefix assignment which is
  described in the following section 5.1.

What does it mean for a router to assign a prefix to a host?  Do you mean "advertise a prefix on a link to which hosts are connected?"

  Another limitation of DHCPv6 reconfiguration is that it only allows
  the messages to be delivered to unicast addresses. So if we want to
  use it for bulk renumbering, stateless DHCPv6 reconfiguration with
  multicast may be needed. However, this may involve protocol
  modification.

This is not accurate.  The DHCPv6 server has a complete list of all clients on any given link.  It can issue unicast reconfigure messages to each client, if desired.  Multicast DHCPv6 reconfigure is not an option, because it's too easy to use it for a DoS attack.

I notice also that you don't mention the 'A' bit in router advertisements.  I think this bit also affects the behavior of various stacks; I'm not sure, but I think it probably should be discussed.

Section 6.1 talks about DDNS as a way to update IP addresses on names during a renumbering event.  I'm not at all clear on what the use model for this would be.  If we're renumbering servers, then certainly you could configure each server with its own key to use for doing updates, so that it could poke its new SLAAC- or DHCPv6-derived address into the DNS.  I'm not sure this is a good _idea_, but it's eminently doable.

As for non-server hosts, have the authors read RFC 4704?  For hosts that are numbered using DHCP, RFC 4704 addresses this problem.

It would certainly be helpful to have support for automatic renumbering on the DNS server, or to use the DHCP server to do renumbering, in cases where this makes sense, but I think that in practice either you have an IPAM system that's going to do all the poking around, or you are using DHCPv6 for non-server hosts and DDNS for server hosts, or the sysadmin is going in and manually changing settings.  I hate this last solution, but if it's ten servers, that's not the end of the world.  It would not work in a cloud hosting environment or anything like that, but I don't get the impression that that is the use case this document is addressing.

The document also mentions A6 records, which are deprecated (RFC 6563), and therefore ought not to be mentioned.

(Addresses of DHCPv6 servers do not  need to be updated. They are dynamically discovered using DHCPv6 relevant multicast addresses.)

While this could be true in principle, it isn't true in practice, because most relay agents have the option of being configured with DHCPv6 server addresses rather than sending to a multicast address, and I think it's more common to do unicast than multicast for this step.  So the document shouldn't assume that this is a solved problem.  Even in the case of multicast, it's necessary for multicast routing to be configured and working in order for DHCP messages to find their way to servers.  In theory a renumbering event shouldn't break multicast routing, but in practice it might.

  The DNS server addresses for hosts could be configured by DHCPv6. In
  stateless DHCPv6 mode [RFC3736], [RFC4242] allows the server to
  specify valid time for the DNS configuration. But in stateful DHCPv6,
  current protocols could not indicate hosts the valid time of DNS
  configuration. If the DNS server has been renumbered, and the DHCP
  lease time has not expired yet, then the hosts would still use the
  old DNS server address(es). It might be better that the hosts could
  renew the DHCP DNS configuration before the lease time, especially
  there might be some extreme situations that the lease time need to be
  long. In this case how the DHCP server could learn the proper DNS
  configuration valid time is also an issue.

There are a bunch of problems with this.  First, the stateful DHCP T1 and T2 times are effectively equivalent to the stateless DHCP Information Refresh Timer (DHCPv6 doesn't talk about leases or lease times, so this term should not be used; rather, addresses have lifetimes, and IAs have T1 and T2 timers that indicate to the client when to renew or rebind, respectively).  So there is no need for an additional timer in stateful DHCPv6; indeed, it doesn't make sense to add one just for renumbering.  How would you know what value to set it to?  Why wouldn't you just set T1 to that value?

Next problem: in a typical renumbering scenario, the old and new prefixes are both valid.  The old prefix is deprecated, but still works.  So the DNS server is still reachable at the old address: there is no interruption of service.  Deprecated addresses and prefixes decay gracefully, so that by the time they are gone, everybody has renumbered.  Hence, the scenario being described here should never happen unless someone unconfigures the deprecated address on the DNS server before all the hosts have stopped using it.  That would be an administrative error.

Section 6.3 appears to be a pair of solutions, not a gap.  It is described as a gap, in the sense that the solutions are lacking, but it's not describing the actual gap.  This seems to be putting the cart before the horse.  The right thing to do is to identify the gap that this solution would fill, rather than describing the absence of these solutions as a gap.

I think you can probably get a gap out of these solutions pretty easily.  It's that there isn't a way to trigger configuration updates for all the subsystems on a server, and all the external databases that refer to that server, on the basis of a change to the server's IP address.  Then you don't need to talk about two solutions, because they both do the same thing; just in different ways.

More examples in this section might help: I think the tunnel endpoint example is a really good one to use.  There are probably some other examples that would be good here—e.g., I have static IP addresses configured in my nginx configuration.  This isn't really a gap—I ought to just put domain names in.  But unless the tunnel endpoint or nginx notices that the addresses returned for that domain name have changed, it will keep blindly using the old address until something triggers it to do a refresh or a restart.  You mention this in 5.2, but it should be mentioned here as well, since as far as I know most services do not actually refresh DNS information until they are triggered somehow to do so.

In section 7.2, what do you mean by "no mechanisms?"  There are mechanisms—if you know a renumbering event is coming up, you probably ought to shorten your TTLs.  This won't work if you have no advance notice of the renumbering event, but the document _seems_ to be talking about orderly renumbering.

If you are doing an orderly renumbering, where the old prefix is deprecated and the new prefix is added, then your TTL may be longer than the time to the deprecation of the old prefix.  This should be avoided—your SLA with the ISP should state a notice period for renumbering that is longer than your TTL, or to put it the other way, your TTL should be shorter than the notice period.  RFC 4192 Section 2.2 talks about this at length, so I presume the authors of this document are familiar with the process.

Is the gap you are talking about the lack of a way to set all the TTLs for a site to no more than a particular value?  If so, that is not clear here.  Or is it the lack of a way to update the names, first adding the new addresses, and later removing the old addresses?  Again, if that is what is intended, it should be made clear.

Section 10.2 mentions the A6 record again.  I don't think this is helpful, because it died for a reason.  I think you should leave this out.  Also, I think you need to lead in with the authority problem—my first read of this section really puzzled me, because it seemed to be talking about a problem that is easy to solve, and it was only when I saw the acknowledgement in section 13 that I went and read the chown draft and then reread section 10.2 and understood what the gap was that was being documented.

It looks like 10.3, second bullet, is talking about the problem I mentioned in 6.3 with services not refreshing DNS information.  I think the techniques you talk about in 6.3 can address this problem, so I don't think it's an unaddressable gap.

[Ballot discuss]
In section 7, you miss a discussion regarding the host/router unique id in the NMS applications
Let's start with syslog, SNMP notification, and IPFIX. For all of these protocols, the host or router id is the UDP message source IP address. Sometimes this matches the device loopback IP address: indeed, we can force the loopback IP address as the source IP address for IPFIX/syslog message/SNMP notifications.
If the source IP address is changed (whether it matches the loopback is irrelevant), the syslogd, trapd, or IPFIX collector will consider that a new device appeared in the network. This is a problem.
I don't want to say that the IP address mapping must be sent in band (i.e. in SNMP, syslog, or IPFIX), maybe updating DNS is sufficient, maybe querying a UUID is the solution, or maybe the solution depends on the protocol (sending the MAC or a UUID in IPFIX would help, as Options Template Record). So maybe there are different solutions for the different protocols.
A discussion/some text is required concerning the host and router unique IDs in NMS applications: these applications should be aware of the IP address mapping.
This might lead to some extra bullet point in the section 9.4

[Ballot comment]
I agree with Stephen's comment: 

    - The write-up notes that this is similar to RFC 6879 which
    is recent, on the same topic and has overlapping authors. I
    was surprised the intro didn't say why this is different. Are
    we sure there is no conflicting advice in the two documents?

The relationship with RFC 6879 should be clearly mentioned.
The relationship between the various documents was already my feedback for RFC 6879. See https://datatracker.ietf.org/doc/draft-ietf-6renum-enterprise/ballot/#benoit-claise

- When I arrive at section 4, I was not too sure if you intended to match section 4 t o7 with

  The automation can be divided into four aspects as follows.

  o Prefix delegation and delivery should be automatic and accurate in
      aggregation and coordination.

  o Address reconfiguration should be automatically achieved through
      standard protocols with minimum human intervention.

  o Address-relevant entry updates should be performed integrally and
      without error.

  o Renumbering event management is needed to provide the functions of
      renumbering notification, synchronization, and monitoring.

I had to carefully match those four points with the section titles.
It was not too clear if "managing prefixes" is treating "Prefix delegation and delivery"

  4. Managing Prefixes ............................................ 7
  5. Address Configuration ........................................ 8
  6. Updating Address-relevant Entries ........................... 10
  7. Renumbering Event Management ................................ 13

You should make it easier for the reader.
Either match the section titles and/or use references:

  The automation can be divided into four aspects as follows.

  o Prefix delegation and delivery should be automatic and accurate in
      aggregation and coordination. See section 4.

  o Address reconfiguration should be automatically achieved through
      standard protocols with minimum human intervention. See section 5

  o Address-relevant entry updates should be performed integrally and
      without error. See section 6

  o Renumbering event management is needed to provide the functions of
      renumbering notification, synchronization, and monitoring. See
      section 7

[Ballot comment]
Just checking on whether these are things people think about when renumbering:

0) s11, prefix validation: Is there any reason it's not: "Prefixes from the ISP need authentication to prevent prefix fraud."  In other words what's up with the "may"; when wouldn't you need authentication?

1) s11: Do you also need to discuss issues with long-lived sessions and how to keep them alive or not (e.g., ssh connections)?

2) s11, influence on security controls:

a) If there's DHCPv6 authentication keys associated with an IP address they'll need to be changed for it to continue working - no?  Addresses in SEND certificates are going to need to get updated.  Are these further examples of what you were thinking or is this more about keeping the security up and running during the transition?

b) More generally, you can include IP addresses in certificates and if you go and renumber those protocols might, well really will, stop working until you reissue a new certificate with a new address.  Is this covered someplace else, does everybody know to do this reissue dance, or should there be a new section "Influence on Security Protocols"?

[Ballot comment]

- The write-up notes that this is similar to RFC 6879 which
is recent, on the same topic and has overlapping authors. I
was surprised the intro didn't say why this is different. Are
we sure there is no conflicting advice in the two documents?

- Surely there's a gap in re-numbering when both v4 and v6
numbers have to change at once - why isn't that mentioned
here? (I assume because of the wg charter or something.)

- p5: "performed integrally" isn't very clear but I think I
get that you mean as an atomic operation or something

- section 2 last para, not clear to me what you're saying
about SLAAC - sentence is odd

- p6: "like [cfengine]" is not so nice as a way to reference
whatever that might be, same for others

- p8, what is "M/O"? you should say

- p11, what is "a gao"?

- p12, presumably automated approaches like LEROY increase
the risk since a bad actor with the right permission could
cause havoc - is that noted?

- p13, presumably changing DNS RRs means signing things if
DNSSEC is in use - is that noted?

- p14, ingress filtering - if I could tell an ISP to no
longer drop packets with sources from prefix X (because I
claim to be renumbering) then I would defeat anti-spoofing
measures - is that noted?

- 7.2 - do DNSSEC RRSIG validity periods play into this too?

- general: if addresses for mail servers are exposed via SPF,
then presumably those will need renumbering too; renumbering
might also trigger false positives or negatives for anti-spam
features (not sure what v6 stuff is being done for DNS RBLs)

- I think section 11 should note that if you do attempt to
fill soem of these gaps, then you may create new threats and
those will also need to be addressed; and some of those
will be *very* hard problems to solve

[Ballot comment]
I support the publication of this document and only have a few, non-blocking, comments/questions...

1. This document is clearly focused on the planned renumbering events within a network and does not address the issues surrounding emergency renumbering events.  Did the WG consider the two distinct cases?  Would it make sense to add some text to the Abstract/Intro highlighting the focus so people don't think this document covers emergency renumbering events?

2. It may be useful to point out in either 3.1 or 3.3 that administrators can leverage the address selection policy distribution mechanism in draft-ietf-6man-addr-select-opt to update the address selection policies on hosts during renumbering.

3. The 2nd paragraph in 5.1 is rather obtuse.  It says that combining SLAAC and DHCP-based address configuration "would add more or less additional complexity". I would think that it would add complexity, period.  It might be useful to reword this to make the meaning clear.

4. In 7.1, it mentions a possible notification mechanism to signal a change in the DNS system related to a renumbering event.  It may be worth mentioning that such a notification mechanism will need a robust security model.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-6renum-gap-analysis-05, which is currently
in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA
Actions that need completion.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (IPv6 Site Renumbering Gap Analysis) to Informational RFC


The IESG has received a request from the IPv6 Site Renumbering WG
(6renum) to consider the following document:
- 'IPv6 Site Renumbering Gap Analysis'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-04-10. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document briefly introduces the existing mechanisms that could
  be utilized for IPv6 site renumbering and tries to cover most of the
  explicit issues and requirements of IPv6 renumbering. Through the gap
  analysis, the document provides a basis for future works that
  identify and develop solutions or to stimulate such development as
  appropriate. The gap analysis is presented following a renumbering
  event procedure summary.






The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-6renum-gap-analysis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-6renum-gap-analysis/ballot/


No IPR declarations have been submitted directly on this I-D.

Renumbering touches a lot of problem areas right now, from multihoming, to host mobilitity, to application persistance across multiple areas and working groups. As a result I'd like to ask for an IETF last call on the gap analysis.

A final check will be made at IETF85 to ensure the WG is happy with the changes made in response to WGLC. If so, will advance to IESG.