Skip to main content

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

Yes

(Joel Jaeggli)

No Objection

(Adrian Farrel)
(Barry Leiba)
(Gonzalo Camarillo)
(Jari Arkko)
(Martin Stiemerling)
(Pete Resnick)
(Richard Barnes)
(Spencer Dawkins)
(Stewart Bryant)

Note: This ballot was opened for revision 06 and is now closed.

Joel Jaeggli Former IESG member
Yes
Yes (for -06) Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Benoît Claise Former IESG member
(was Discuss) No Objection
No Objection (2013-06-24) Unknown
Thanks for addressing my DISCUSS
Brian Haberman Former IESG member
No Objection
No Objection (2013-05-13 for -07) Unknown
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.
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Richard Barnes Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Sean Turner Former IESG member
No Objection
No Objection (2013-05-14 for -07) Unknown
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"?
Spencer Dawkins Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2013-05-14 for -07) Unknown
- 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
Stewart Bryant Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Ted Lemon Former IESG member
(was Discuss) No Objection
No Objection (2013-06-17) Unknown
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...