IPv6 Site Renumbering Gap Analysis
draft-ietf-6renum-gap-analysis-08
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2013-08-23
|
08 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2013-07-25
|
08 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2013-07-11
|
08 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent |
2013-07-11
|
08 | (System) | RFC Editor state changed to EDIT |
2013-07-11
|
08 | (System) | Announcement was received by RFC Editor |
2013-07-11
|
08 | (System) | IANA Action state changed to No IC from In Progress |
2013-07-11
|
08 | (System) | IANA Action state changed to In Progress |
2013-07-11
|
08 | Cindy Morgan | State changed to Approved-announcement sent from Approved-announcement to be sent |
2013-07-11
|
08 | Cindy Morgan | IESG has approved the document |
2013-07-11
|
08 | Cindy Morgan | Closed "Approve" ballot |
2013-07-11
|
08 | Cindy Morgan | Ballot writeup was changed |
2013-07-11
|
08 | Cindy Morgan | Ballot approval text was generated |
2013-06-30
|
08 | Joel Jaeggli | Note sent to rfc-editor please announce |
2013-06-30
|
08 | Joel Jaeggli | State changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed |
2013-06-30
|
08 | Joel Jaeggli | Ballot approval text was changed |
2013-06-30
|
08 | Joel Jaeggli | Changed consensus to Yes from Unknown |
2013-06-27
|
08 | Cindy Morgan | State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation::AD Followup |
2013-06-27
|
08 | Amanda Baber | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2013-06-24
|
08 | Benoît Claise | [Ballot comment] Thanks for addressing my DISCUSS |
2013-06-24
|
08 | Benoît Claise | [Ballot Position Update] Position for Benoit Claise has been changed to No Objection from Discuss |
2013-06-21
|
08 | Joel Jaeggli | Telechat date has been changed to 2013-06-27 from 2013-05-16 |
2013-06-17
|
08 | Ted Lemon | [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 … [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... |
2013-06-17
|
08 | Ted Lemon | [Ballot Position Update] Position for Ted Lemon has been changed to No Objection from Discuss |
2013-06-10
|
08 | Benoît Claise | [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 … [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. |
2013-06-10
|
08 | Benoît Claise | Ballot comment and discuss text updated for Benoit Claise |
2013-06-09
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2013-06-09
|
08 | Bing Liu | New version available: draft-ietf-6renum-gap-analysis-08.txt |
2013-05-16
|
07 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'No Response' |
2013-05-16
|
07 | Cindy Morgan | State changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2013-05-16
|
07 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2013-05-15
|
07 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2013-05-15
|
07 | Ted Lemon | [Ballot comment] Suggestion in section 2: OLD: o Hosts that are configured through DHCPv6 [RFC3315] can reconfigure addresses by … [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... |
2013-05-15
|
07 | Ted Lemon | Ballot comment text updated for Ted Lemon |
2013-05-15
|
07 | Ted Lemon | [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 … [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. |
2013-05-15
|
07 | Ted Lemon | [Ballot comment] Suggestion in section 2: OLD: o Hosts that are configured through DHCPv6 [RFC3315] can reconfigure addresses by … [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... |
2013-05-15
|
07 | Ted Lemon | Ballot comment and discuss text updated for Ted Lemon |
2013-05-15
|
07 | Ted Lemon | [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 … [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. |
2013-05-15
|
07 | Ted Lemon | [Ballot comment] Suggestion: OLD: o Hosts that are configured through DHCPv6 [RFC3315] can reconfigure addresses by starting RENEW actions … [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. |
2013-05-15
|
07 | Ted Lemon | Ballot comment and discuss text updated for Ted Lemon |
2013-05-15
|
07 | Ted Lemon | [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 … [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. |
2013-05-15
|
07 | Ted Lemon | [Ballot comment] Suggestion: OLD: o Hosts that are configured through DHCPv6 [RFC3315] can reconfigure addresses by starting RENEW actions … [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. |
2013-05-15
|
07 | Ted Lemon | [Ballot Position Update] New position, Discuss, has been recorded for Ted Lemon |
2013-05-15
|
07 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2013-05-15
|
07 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2013-05-15
|
07 | Benoît Claise | [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 … [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 |
2013-05-15
|
07 | Benoît Claise | [Ballot comment] I agree with Stephen's comment: - The write-up notes that this is similar to RFC 6879 which is recent, … [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 |
2013-05-15
|
07 | Benoît Claise | [Ballot Position Update] New position, Discuss, has been recorded for Benoit Claise |
2013-05-15
|
07 | Richard Barnes | [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes |
2013-05-14
|
07 | Sean Turner | [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 … [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"? |
2013-05-14
|
07 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner |
2013-05-14
|
07 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2013-05-14
|
07 | Stephen Farrell | [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 … [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 |
2013-05-14
|
07 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2013-05-13
|
07 | Brian Haberman | [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 … [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. |
2013-05-13
|
07 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2013-05-12
|
07 | Joel Jaeggli | State changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
2013-05-10
|
07 | Robert Sparks | Request for Telechat review by GENART Completed: Ready. Reviewer: Robert Sparks. |
2013-05-10
|
07 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2013-05-10
|
07 | Bing Liu | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2013-05-10
|
07 | Bing Liu | New version available: draft-ietf-6renum-gap-analysis-07.txt |
2013-05-10
|
06 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2013-05-03
|
06 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2013-05-02
|
06 | Jean Mahoney | Request for Telechat review by GENART is assigned to Robert Sparks |
2013-05-02
|
06 | Jean Mahoney | Request for Telechat review by GENART is assigned to Robert Sparks |
2013-04-30
|
06 | (System) | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2013-04-30
|
06 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Review Needed |
2013-04-30
|
06 | Joel Jaeggli | Ballot has been issued |
2013-04-30
|
06 | Joel Jaeggli | [Ballot Position Update] New position, Yes, has been recorded for Joel Jaeggli |
2013-04-30
|
06 | Joel Jaeggli | Created "Approve" ballot |
2013-04-30
|
06 | Joel Jaeggli | Ballot writeup was changed |
2013-04-26
|
06 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2013-04-26
|
06 | Bing Liu | New version available: draft-ietf-6renum-gap-analysis-06.txt |
2013-04-16
|
05 | Joel Jaeggli | Placed on agenda for telechat - 2013-05-16 |
2013-04-16
|
05 | Joel Jaeggli | State changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead |
2013-04-10
|
05 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2013-04-01
|
05 | Robert Sparks | Request for Last Call review by GENART Completed: Not Ready. Reviewer: Robert Sparks. |
2013-04-01
|
05 | (System) | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2013-04-01
|
05 | Pearl Liang | 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 … 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. |
2013-03-29
|
05 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Eric Rescorla |
2013-03-29
|
05 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Eric Rescorla |
2013-03-28
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Robert Sparks |
2013-03-28
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Robert Sparks |
2013-03-27
|
05 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2013-03-27
|
05 | Cindy Morgan | 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 … 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. |
2013-03-27
|
05 | Cindy Morgan | State changed to In Last Call from Last Call Requested |
2013-03-27
|
05 | Cindy Morgan | Last call announcement was generated |
2013-03-26
|
05 | Joel Jaeggli | Last call was requested |
2013-03-26
|
05 | Joel Jaeggli | Last call announcement was generated |
2013-03-26
|
05 | Joel Jaeggli | Ballot writeup was generated |
2013-03-26
|
05 | Joel Jaeggli | 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 … 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. |
2013-03-26
|
05 | Joel Jaeggli | State changed to Last Call Requested from AD Evaluation |
2013-03-26
|
05 | Joel Jaeggli | A superficial read of this seems fine, I'm reviewing the last call commentary. |
2013-03-26
|
05 | Joel Jaeggli | State changed to AD Evaluation from Publication Requested |
2013-03-25
|
05 | Joel Jaeggli | Changed protocol writeup |
2013-03-14
|
05 | Joel Jaeggli | Ballot approval text was generated |
2013-03-14
|
05 | Joel Jaeggli | IESG process started in state Publication Requested |
2013-03-14
|
05 | (System) | Earlier history may be found in the Comment Log for draft-liu-6renum-gap-analysis |
2013-02-20
|
05 | Joel Jaeggli | Shepherding AD changed to Ronald Bonica |
2013-02-20
|
05 | Joel Jaeggli | Shepherding AD changed to Ronald Bonica |
2013-02-20
|
05 | Joel Jaeggli | Shepherding AD changed to Ronald Bonica |
2013-02-20
|
05 | Joel Jaeggli | Shepherding AD changed to Ronald Bonica |
2013-02-20
|
05 | Tim Chown | Intended Status changed to Informational from None |
2013-02-20
|
05 | Tim Chown | Changed shepherd to Tim Chown |
2013-01-21
|
05 | Tim Chown | IETF state changed to Submitted to IESG for Publication from In WG Last Call |
2013-01-21
|
05 | Tim Chown | Annotation tag Doc Shepherd Follow-up Underway cleared. |
2013-01-21
|
05 | Tim Chown | IETF state changed to In WG Last Call from Waiting for WG Chair Go-Ahead |
2013-01-21
|
05 | Tim Chown | Annotation tag Doc Shepherd Follow-up Underway set. |
2012-12-12
|
05 | Bing Liu | New version available: draft-ietf-6renum-gap-analysis-05.txt |
2012-10-28
|
04 | Tim Chown | IETF state changed to Waiting for WG Chair Go-Ahead from WG Document |
2012-10-15
|
04 | Tim Chown | 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 … 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. |
2012-10-15
|
04 | Bing Liu | New version available: draft-ietf-6renum-gap-analysis-04.txt |
2012-09-03
|
03 | Sheng Jiang | New version available: draft-ietf-6renum-gap-analysis-03.txt |
2012-07-16
|
02 | Bing Liu | New version available: draft-ietf-6renum-gap-analysis-02.txt |
2012-03-12
|
01 | Bing Liu | New version available: draft-ietf-6renum-gap-analysis-01.txt |
2012-02-06
|
00 | (System) | New version available: draft-ietf-6renum-gap-analysis-00.txt |