Re: Why does everyone see router renumbnering as hard? (was Re: draft-ietf-ipv6-ula-central-02.txt and NAT)
On Wed, Jun 20, 2007 at 12:27:17PM +0200, Eliot Lear wrote: There are two that I can point you at, and perhaps the temporal difference would be at least amusing: * Renumbering: Threat or Menace?, Lear, Katinsky, Tharp, et al, Proceedings of the Tenth Systems Administration Conference (LISA96) * Procedures for Renumbering an IPv6 Network Without a Flag Day, Baker, Lear, Droms, RFC 4192, September, 2005. I would also add that Tim Chown has done an extensive amount of work in this space. Well, it was the 6NET team, and some documentation can be found here: http://www.6net.org/publications/deliverables/D3.6.1.pdf http://www.6net.org/publications/deliverables/D3.6.2.pdf and also Chown, T., Thompson, M., Ford, A., and S. Venaas, Things to think about when Renumbering an IPv6 network (draft-chown-v6ops-renumber-thinkabout-05.txt), March 2007. but the feeling in v6ops certainly seems to be 'we don't want to renumber, we'd rather have PI or look at id/loc longer term' so specific effort on making renumbering easier isn't really being made (in that wg at least). If your point is that you should never have to renumber, then that's a lovely way to go. It will still happen, of course, as companies merge and grow. I think IPv6 helps with the latter, but the former is still a challenge simply because topologies change. IPv6 certainly helps, but doesn't trivialise it by any means. -- Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Why does everyone see router renumbnering as hard? (was Re: draft-ietf-ipv6-ula-central-02.txt and NAT)
On Jun 20, 2007, at 3:11 AM, Jeroen Massar wrote: I think there has been hype on both sides of this question. Router renumbering used to be VERY annoying. I've now published several times on the subject Any links to the papers? A paper which in-my-non-humble-opinion covers a lot of the bases is http://www.ietf.org/rfc/rfc4192.txt 4192 Procedures for Renumbering an IPv6 Network without a Flag Day. F. Baker, E. Lear, R. Droms. September 2005. (Format: TXT=52110 bytes) (Updates RFC2072) (Status: INFORMATIONAL) Actually, all renumbering is trivial, as long as nobody every actually writes down an address and always uses a name. The problem is - there are any number of places where people either are forced to or in fact do choose to write down an address. As soon as that happens, that is a place that has to be remembered and written again when the address needs to be changed. Documentation and human memory being what it is, every place where an address gets written down is a place that will be re-discovered because something isn't working as expected when a renumbering happens. The ideal thing, of course, is that all configurations of all equipment are centrally managed from a common database, and all one has to do is change the database. the. It's an english word with a very interesting property. It is *singular*. As a result, it is very rarely the right word... PGP.sig Description: This is a digitally signed message part IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Why does everyone see router renumbnering as hard? (was Re: draft-ietf-ipv6-ula-central-02.txt and NAT)
On Jun 19, 2007, at 5:41 PM, Mark Andrews wrote: I would have thought that router renumbering should be no harder that host renumbering. Essentially all you are changing is the higher (/48 normally) prefix bits. assuming that all prefixes are 48 bits long, fine. Guess what. That's only the *first* broken assumption... IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Why does everyone see router renumbnering as hard? (was Re: draft-ietf-ipv6-ula-central-02.txt and NAT)
Mark Andrews wrote: I would have thought that router renumbering should be no harder that host renumbering. Essentially all you are changing is the higher (/48 normally) prefix bits. All that is required is a method to distribute the set of prefixes in use with a set of tags (global, deprecated, ula, advertise in RA, etc.). I think there has been hype on both sides of this question. Router renumbering used to be VERY annoying. I've now published several times on the subject and I can say that it's not as hard as it was, but it's not as easy as it could be. Specifically, prefix delegation should do the job for small routers, particularly in the consumer market. Making use of PD in the enterprise is more experimental, I would say, because, as Bill alludes, there are quite a number of knobs to play with. Consider that a typical enterprise router not only has interface addresses and routing subsystems and firewalls, but may also have such fun as VRRP/HSRP configurations, load balancing capabilities, NetFlow/sflow collectors, multicast configuration that has some unicast addresses hidden in it, management configuration (e.g., SNMP, SYSLOG, other), and the like. In my opinion, this means that the router of the future needs to look a little different, and this has implications for other subsystems. Much of this could conceivably be hidden with DNS, but the router itself needs to function not just deterministically but predictably down to the minute in terms of which addresses it is using. DNS isn't very good at that because your TTLs are based on when you query, and are tied to relatively fixed configurations, but it can be used for many things even so. And today you can do that in many portions of the configuration - but not all. It is possible to abstract out much of the configuration EVEN WITHOUT DNS, and modularize those things that will change. And we've done *some* of that at Cisco, but we all could do more. Eliot IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Why does everyone see router renumbnering as hard? (was Re: draft-ietf-ipv6-ula-central-02.txt and NAT)
Eliot Lear wrote: Mark Andrews wrote: I would have thought that router renumbering should be no harder that host renumbering. Essentially all you are changing is the higher (/48 normally) prefix bits. All that is required is a method to distribute the set of prefixes in use with a set of tags (global, deprecated, ula, advertise in RA, etc.). I think there has been hype on both sides of this question. Router renumbering used to be VERY annoying. I've now published several times on the subject Any links to the papers? and I can say that it's not as hard as it was, but it's not as easy as it could be. Specifically, prefix delegation should do the job for small routers, particularly in the consumer market. Making use of PD in the enterprise is more experimental, I would say, because, as Bill alludes, there are quite a number of knobs to play with. Consider that a typical enterprise router not only has interface addresses and routing subsystems and firewalls, but may also have such fun as VRRP/HSRP configurations, load balancing capabilities, NetFlow/sflow collectors, multicast configuration that has some unicast addresses hidden in it, management configuration (e.g., SNMP, SYSLOG, other), and the like. Indeed, but except for firewalling, it is why I mentioned using a local space (PI) or some other 'globally unique chunk that they can keep'. One will then configure all the internal setups (snmp,syslog,sflow/netflow etc) using the forever addresses and won't have to care about those anymore. Routing internally can also happen using those addresses, though the scary bit is of course when the MTU does change or a Host/Net unreach has to be sent, the router has to pick the correct global address and not the one which is only used inside the network. A block like fc00::/7 could make it easy to then choose the address based on the target, but how sure are you that the other organization is not using global unicast space for their internal networks? Even if that dual setup might not be accepted everywhere, I mean if you have PI why should one want to add the mess of two networks? In my opinion, this means that the router of the future needs to look a little different, and this has implications for other subsystems. [..goodbits..] Which is indeed why I am thinking that ID/LOC is the way to go. One internal prefix on the local network, and whatever prefix is on the global Internet. Apply ID/LOC when your packets are going somewhere where you can't use your local prefix. Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Why does everyone see router renumbnering as hard? (was Re: draft-ietf-ipv6-ula-central-02.txt and NAT)
Jeroen Massar wrote: Eliot Lear wrote: Mark Andrews wrote: I would have thought that router renumbering should be no harder that host renumbering. Essentially all you are changing is the higher (/48 normally) prefix bits. All that is required is a method to distribute the set of prefixes in use with a set of tags (global, deprecated, ula, advertise in RA, etc.). I think there has been hype on both sides of this question. Router renumbering used to be VERY annoying. I've now published several times on the subject Any links to the papers? There are two that I can point you at, and perhaps the temporal difference would be at least amusing: * Renumbering: Threat or Menace?, Lear, Katinsky, Tharp, et al, Proceedings of the Tenth Systems Administration Conference (LISA96) * Procedures for Renumbering an IPv6 Network Without a Flag Day, Baker, Lear, Droms, RFC 4192, September, 2005. I would also add that Tim Chown has done an extensive amount of work in this space. Indeed, but except for firewalling, it is why I mentioned using a local space (PI) or some other 'globally unique chunk that they can keep'. Certainly we've heard this argument from large enterprise customers. One will then configure all the internal setups (snmp,syslog,sflow/netflow etc) using the forever addresses and won't have to care about those anymore. Sure. Routing internally can also happen using those addresses, though the scary bit is of course when the MTU does change or a Host/Net unreach has to be sent, the router has to pick the correct global address and not the one which is only used inside the network. This really depends on just how scary an enterprise routing configuration is. They can be quite complex depending on both their internal and external connectivity, and each has some implications for the other. There are quite a number of enterprises that make heavy use of BGP internally. But certainly the point of ULAs was to provide some stability in this area. I think LISP (draft-farinacci-lisp-00.txt) has promise here as well, as may Robin's iVIP proposal (see the ram archives for details). In my opinion, this means that the router of the future needs to look a little different, and this has implications for other subsystems. [..goodbits..] Which is indeed why I am thinking that ID/LOC is the way to go. One internal prefix on the local network, and whatever prefix is on the global Internet. Apply ID/LOC when your packets are going somewhere where you can't use your local prefix. If your point is that you should never have to renumber, then that's a lovely way to go. It will still happen, of course, as companies merge and grow. I think IPv6 helps with the latter, but the former is still a challenge simply because topologies change. Eliot IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: Why does everyone see router renumbnering as hard? (was Re: draft-ietf-ipv6-ula-central-02.txt and NAT)
In my opinion, this means that the router of the future needs to look a little different, and this has implications for other subsystems. Much of this could conceivably be hidden with DNS, Since when do IP networks require DNS to function. We run a global IPv4 network with over 10,000 customer sites in over 20 countries, and there is virtually no DNS on this network at all. After all, it's an IP network, i.e. its job is forwarding IP packets. As to why DNS is not used, it has something to do with unneccesarily trusting third parties to figure out your packet destinations and the added complexity of DNS. It turns out to be simpler and more flexible to just use IP addresses directly. If you need to fail-over communications to a disaster-recovery site, or merely to a backup server, you can configure two or four IP addresses in the application and let the app sort out where to send packets. DNS should not be overloaded with so many new functions that it becomes a requirement of running an IP network. --Michael Dillon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Why does everyone see router renumbnering as hard? (was Re: draft-ietf-ipv6-ula-central-02.txt and NAT)
Michael, I totally understand the concern over circular dependencies. They are not to be underestimated. And in a service provider environment I think you must be doubly cautious about them. However, in an enterprise environment it may be appropriate to make certain allowances for certain services, and under certain circumstances. For instance, a load balancer may require DNS to be functioning already in order for it to service requests. Similarly, it may be possible to secondary a zone in order to be able to bring up certain other services, such as NTP. It is *even* possible to retain policy in DNS if one really wants to do so under such circumstances, but one has to at that point consider what your failsafe is. Ultimately, however, the administrative issues of renumbering revolve around an inability to abstract IP address information. In solving that problem, however one performs the dereference from abstract to concrete, one must worry about dependency loops. A configuration server could just as easily be unavailable, for instance, as a name server. Eliot IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Why does everyone see router renumbnering as hard? (was Re: draft-ietf-ipv6-ula-central-02.txt and NAT)
I would have thought that router renumbering should be no harder that host renumbering. Essentially all you are changing is the higher (/48 normally) prefix bits. All that is required is a method to distribute the set of prefixes in use with a set of tags (global, deprecated, ula, advertise in RA, etc.). Everything else should flow from that set. Firewall rules should be using that information as it really doesn't matter which global prefix a host uses to talk to the world. They are all essentially equal. I may we be showing my ignorance here but I don't believe that this really is a to hard job. Mark This prompted a jabber discussion extracts of which follow. X note that people who operate routers are usually all about control. automatic renumbering is scary except maybe on the edge marka There is no loss of control. It would still require a human to add a prefix to the set of prefixes in use. X somebody upstream from you renumbers. what happens? marka With IPv6 I would expect that a both the new and old routes would be published for a period. The old route would then be withdrawn. There is plenty of addresses space. There is no need for instantious changes in addresses. X i was talking about control. your upstream adds new prefix, do you add automatically or do you wait for human to approve it? X simiarly for your upstream withdrawing, do you withdraw automatically or ... marka I would expect that there would be due notice give so that humans could be involved. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Why does everyone see router renumbnering as hard? (was Re: draft-ietf-ipv6-ula-central-02.txt and NAT)
no renumbering event is too hard in isolation .. BGP peers, MRTG/CRICKET monitoring, /ACL configs, syslog all come to mind as issues/considerations for router renumbering. and remember tht the router is the distribution engine of the set of prefixes in use with a set of tags (global, deprecated, etc) one has to be very careful about catch22 situations, deprecating the in use prefixes before the new prefixes are in use. operationally, renumbering DNS/DHCP servers is a whole lot easier. --bill On Wed, Jun 20, 2007 at 10:41:33AM +1000, Mark Andrews wrote: I would have thought that router renumbering should be no harder that host renumbering. Essentially all you are changing is the higher (/48 normally) prefix bits. All that is required is a method to distribute the set of prefixes in use with a set of tags (global, deprecated, ula, advertise in RA, etc.). Everything else should flow from that set. Firewall rules should be using that information as it really doesn't matter which global prefix a host uses to talk to the world. They are all essentially equal. I may we be showing my ignorance here but I don't believe that this really is a to hard job. Mark Jeroen Massar wrote: The above hosts are Internet connected and most likely will thus also end up talking to the Internet at one point or another. I can thus only guess that they will be wanting to fully connect to the Internet one day and the generic solution to that problem is NAT. We wanted to get rid of NAT for IPv6. If NAT is again being done for IPv6 then we can just as well give up and just keep on using IPv4 as there really is not a single advantage then anymore to IPv6. I think what we wanted to get rid of in IPv6 was one-to-many NAT, also know as PAT (among other names). In IPv6, we can stick to one-to-one NAT, which eliminates most of the nastiness we associate with NAT in today's IPv4 world. But see below for a scenario that might have actual merit here. **SCENARIO** One possible scenario could maybe be: use ULA-C local in your local site, use global (PA) addresses from the upstream ISP, from whom you get a /48 too, thus the number plan is the same, just different first 48 bits. Every host gets a ULA and a PA address. The PA address might change when changing ISP. RFC3484 and related work can be used to configure preferring what address to use. Then you never need to reconfigure your local network and local addresses are globally unique and can use the Internet. The big thing there is though: configure your firewalls correctly as the public addresses do also allow access to everything. I don't think routers are at the point yet where you can easily renumber your routers' interfaces when your PA addresses change. As a result, networks wanting to avoid the pain of renumbering, but who don't qualify for PI and a global routing slot, might want to do something similar: Say a network gets a ULA-C block, and numbers everything on their network out of that block. They later connect to the Internet, and get a PA block from their upstream, and configure it on their border routers. To avoid reconfiguring all their routers every time they change upstreams, they configure one-to-one NAT on their border routers, such that every address on their internal network (which is ULA-C) maps to the same address, except with different first 48 bits, in their provider-allocated block. This wouldn't present the same kinds of problems you'd get from one-to-many NAT, but I'm sure there are some ways where this wouldn't be as good as PI space. However, my first-order evaluation is that it would be better to have small networks achieve their provider independence this way, rather than by relaxing the PI rules and threatening the scalability of the current routing system with a large number of additional non-aggregatable netblocks. Now as expressed earlier, most ULA-C use cases probably won't involve NAT. But if people do elect to use NAT with ULA-C, what problems do you see with this kind of use of NAT? Do you see those problems as worse than the problems caused by completely rejecting the original PA-only architecture of IPv6 in favor of PI-for-everyone? Still, the above can also be accomplished perfectly fine with PI space and that doesn't require any changes (except RIPE+APNIC policy) to be done. I agree that PI space, if it were widely available, would meet the same needs as ULA-C. However, I think we need to be realistic that PI-for-everyone won't fly, and need to think creatively about ways to achieve the same goals (such as provider independence) in such a way that we don't impose more public cost than private
Re: Why does everyone see router renumbnering as hard? (was Re: draft-ietf-ipv6-ula-central-02.txt and NAT)
This prompted a jabber discussion extracts of which follow. X note that people who operate routers are usually all about control. automatic renumbering is scary except maybe on the edge marka There is no loss of control. It would still require a human to add a prefix to the set of prefixes in use. X somebody upstream from you renumbers. what happens? marka With IPv6 I would expect that a both the new and old routes would be published for a period. The old route would then be withdrawn. There is plenty of addresses space. There is no need for instantious changes in addresses. X i was talking about control. your upstream adds new prefix, do you add automatically or do you wait for human to approve it? X simiarly for your upstream withdrawing, do you withdraw automatically or ... marka I would expect that there would be due notice give so that humans could be involved. you expect too much. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -- --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
