Peter,
BTW - I have not studied the RFC's - so what will IPv6 do for us in the contect of routeing aggregation and latger boxes etc ?
Couple of observations:
1. The ability to aggregate routing information depends on how addresses are assigned, but does not depend on whether addresses are 32 bits wide or 128 bits wide.
2. IPv6 address allocation architecture (see draft-ietf-ipngwg-unicst-addr-allo-01.txt) is the same as IPv4. (just so that folks who read this note would have no doubts, the IPv6 Address Allocation Architecture document was written by Tony Li and myself - the same people who wrote the CIDR Address Allocation Architecture document).
Conclusion:
In the area of routing aggregation IPv6 will do for us *exactly the same* as what IPv4 does.
With one notable exception.... No allocation legacies. That is there aren't any old badly-distributed ipv6 addresses floating around. This means that ipv6 aggregation should be substantially more effective than ipv4 CIDR has been.
Yakov.
Owen
Owen,
With one notable exception.... No allocation legacies. That is there aren't any old badly-distributed ipv6 addresses floating around. This means that ipv6 aggregation should be substantially more effective than ipv4 CIDR has been.
It is not the legacy allocations that we're concerned with. It is new allocations that we're worry about. Yakov.
Owen,
Conclusion:
In the area of routing aggregation IPv6 will do for us *exactly the same* as what IPv4 does.
With one notable exception.... No allocation legacies. That is there aren't any old badly-distributed ipv6 addresses floating around. doesn't the transition strategy foresee to embedded the old cluttered IPv4 space into the new supposedly clean IPv6 megaspace... Thus I suspect the allocation legacy will be inherited. While I agree with Yakov that we need to worry about the new allocations, I think that the legacy is large enough that some garbage collection would be well advised - and could be important for survival under current and future growth.
This means that ipv6 aggregation should be substantially more effective than ipv4 CIDR has been.
I guess it can be made more effective, because distributing address space over service providers can be done in ways that allow much more space for growth without renumbering into a new bigger contiguous allocation. With the current scarce IPv4 space forces registries to apply slow start allocations for providers - resulting in multiple prefixes for one provider (or the need to renumber more or less complete provider spaces). Considering this (on the very pessimistic side) two questions come to mind: - it seems to me that so far we only have considered to ask for the renumbering of customer networks (when they switch providers, or to kindly release large, inefficiently used spaces), and maybe small access providers. Will things get so tough that I will have to ask my customers to renumber because I need to switch from a clutter of small spaces (as built in slow start and and with allocations not larger then /16) into a larger single prefix space? - even when I started out with provider aggregatable space, and tell customers that address space cannot be moved to another provider and I'm warning them that using their old numbers we cannot guarantee "full" connectivety. - if large scale renumbering needs to happen, the problem seems to be analog to memory allocation systems (on the fly); I faintly remember that this could mean another factor of ineffeciency for the use of space. How much will this reduce the expected life time of the IPv4 space? (well, of course, under exponential growth it will be not very much) BTW we would need to recognize the need for large scale renumbering a couple of years ahead - else we will not have the tools to do it, not to think about the need to educate network and systems administrators... For a more positive perspective: Can we assume that the current "end of the line" routers can be made to deal safely with 45,000 routes? (Seems 64 MB is ok for this; probably somewhat faster processors would be nice to deal with the updates and flapping; how much more thrust would be needed to deal with the computational complexity of the routing problem at this level?) Considering that 45,000 is already 75% of all possible /16 prefixes, could we define the goal of limiting the number of prefixes to 45,000 or some other (but firmly defined) close number? Assuming - we make wise use of space on the new allocations, - we really drop long prefixes for old cluttered space when we get close to the limit, - the typical topology does not change in ways that are require much more router ressources, - we decide quickly, - and we start communicating this to planners and administrators, I think there could be good chance to survive until a high percentage of v4 space is consumed (and the expected life time of our big boxes might be higher and more secure). This should be sufficient for v6 to survive for some time as well; but of course the question of the limit of number of routes needs to be revisited with some different parameters - and hopefully some additional helpful tools, and maybe some new algorithms. Ruediger
Will things get so tough that I will have to ask my customers to renumber because I need to switch from a clutter of small spaces (as built in slow start and and with allocations not larger then /16) into a larger single prefix space? - even when I started out with provider aggregatable space, and tell customers that address space cannot be moved to another provider and I'm warning them that using their old numbers we cannot guarantee "full" connectivety.
Yes
- if large scale renumbering needs to happen, the problem seems to be analog to memory allocation systems (on the fly); I faintly remember that this could mean another factor of ineffeciency for the use of space. How much will this reduce the expected life time of the IPv4 space? (well, of course, under exponential growth it will be not very much)
Already proposed this model for managment of the IPv4 space.
BTW we would need to recognize the need for large scale renumbering a couple of years ahead - else we will not have the tools to do it, not to think about the need to educate network and systems administrators...
Yup. See the latest draft from the IAB and ftp.isi.edu:/pub/bill/renumbering --bill
Date: Wed, 16 Aug 1995 21:14:19 +0200 From: Ruediger Volk <rv@zeus.NIC.DTAG.DE> Owen, > > Conclusion: > > > > In the area of routing aggregation IPv6 will do for us *exactly the same* > > as what IPv4 does. > > > With one notable exception.... No allocation legacies. That is there aren't > any old badly-distributed ipv6 addresses floating around. doesn't the transition strategy foresee to embedded the old cluttered IPv4 space into the new supposedly clean IPv6 megaspace... Thus I suspect the allocation legacy will be inherited. While I agree with Yakov that we need to worry about the new allocations, I think that the legacy is large enough that some garbage collection would be well advised - and could be important for survival under current and future growth. Ruediger I thought that the IPv6 address space had fields for a provider number outside of the "legacy" IPv4 address space. Thus "legacy" IPv4 networks can be moved by changing the provider bits in the larger IPv6 address. The routers involved will need to be IPv6 capable, but the individual hosts on a lan continue to use their old IPv4 addresses and do *not* need to be renumbered. The IPv4 networks are now "mobile" and can move from provider to provider providing the routers involved all talk IPv6. Please correct me if I'm wrong. I got this from reading a 3 page overview of IPv6 which I can't find at this momemt. -- David.Schmidt@on-ramp.ior.com Internet On-Ramp, Inc. (509)624-RAMP (7267) Spokane, Washington http://www.ior.com/ (509)622-2866 (fax)
David,
I thought that the IPv6 address space had fields for a provider number outside of the "legacy" IPv4 address space. Thus "legacy" IPv4 networks can be moved by changing the provider bits in the larger IPv6 address.
The routers involved will need to be IPv6 capable, but the individual hosts on a lan continue to use their old IPv4 addresses and do *not* need to be renumbered. The IPv4 networks are now "mobile" and can move from provider to provider providing the routers involved all talk IPv6.
In IPv6 there is a notion of "IPv4 compatible" addresses. These are IPv6 addresses (128 bits) that have IPv4 address as their low order 32 bits and the rest (96 bits) are zero. If you look at the IPv6 transition then you'll find that it is a so-called "dual stack" transition, where hosts have to have both IPv4 and IPv6. Moreover, to make transition reasoably simple, hosts should have IPv6 addresses that are "IPv4 compatible". A consequence of this, is that the allocation of IPv6 addresses that are "IPv4 compatible" is *exactly the same* as the current IPv4 allocation. So, "legacy networks" would not be able to move "by changing the provider bits in the larger IPv6 address", as "IPv4 compatible" addresses have no "provider bits". What you said is correct only if hosts use IPv6 addresses that are not "IPv4 compatible". But transition with hosts that don't have IPv4 compatible addresses is quite messy. Yakov.
cc: rv@zeus.nic.dtag.de, owen@delong.sj.ca.us, inet-access@earth.com, nanog@merit.edu, local-ir@ripe.net Date: Thu, 17 Aug 95 06:04:21 PDT From: Yakov Rekhter <yakov@cisco.com> David,
I thought that the IPv6 address space had fields for a provider number outside of the "legacy" IPv4 address space. Thus "legacy" IPv4 networks can be moved by changing the provider bits in the larger IPv6 address.
The routers involved will need to be IPv6 capable, but the individual hosts on a lan continue to use their old IPv4 addresses and do *not* need to be renumbered. The IPv4 networks are now "mobile" and can move from provider to provider providing the routers involved all talk IPv6.
In IPv6 there is a notion of "IPv4 compatible" addresses. These are IPv6 addresses (128 bits) that have IPv4 address as their low order 32 bits and the rest (96 bits) are zero. If you look at the IPv6 transition then you'll find that it is a so-called "dual stack" transition, where hosts have to have both IPv4 and IPv6. Moreover, to make transition reasoably simple, hosts should have IPv6 addresses that are "IPv4 compatible". A consequence of this, is that the allocation of IPv6 addresses that are "IPv4 compatible" is *exactly the same* as the current IPv4 allocation. So, "legacy networks" would not be able to move "by changing the provider bits in the larger IPv6 address", as "IPv4 compatible" addresses have no "provider bits". What you said is correct only if hosts use IPv6 addresses that are not "IPv4 compatible". But transition with hosts that don't have IPv4 compatible addresses is quite messy. Yakov. But isn't it possible to have a router convert from an IPv6 address with provider bits to an IPv4 address by simply stripping all but the lowest 32 bits from the IPv6 address? The hosts on the LAN remain entirely IPv4, but the addresses that leave the router have the provider bits added by the router. Isn't that one of the goals of IPv6? To allow hosts to remain IPv4 and coexist with the IPv6 hosts and backbone? -- David.Schmidt@on-ramp.ior.com Internet On-Ramp, Inc. (509)624-RAMP (7267) Spokane, Washington http://www.ior.com/ (509)622-2866 (fax)
David,
But isn't it possible to have a router convert from an IPv6 address with provider bits to an IPv4 address by simply stripping all but the lowest 32 bits from the IPv6 address?
The hosts on the LAN remain entirely IPv4, but the addresses that leave the router have the provider bits added by the router.
You can't strip a non-zero part of IPv6 address, as this would cause transport layer pseudo-header checksum to fail. Yakov.
But isn't it possible to have a router convert from an IPv6 address with provider bits to an IPv4 address by simply stripping all but the
You can't strip a non-zero part of IPv6 address, as this would cause transport layer pseudo-header checksum to fail.
Unless you recalulate the checksum. There are products out now that do similar things (like map a large set of private ip addresses to a single class C).
Jon,
But isn't it possible to have a router convert from an IPv6 address with provider bits to an IPv4 address by simply stripping all but the
You can't strip a non-zero part of IPv6 address, as this would cause transport layer pseudo-header checksum to fail.
Unless you recalulate the checksum. There are products out now that do similar things (like map a large set of private ip addresses to a single class C).
You're absolutely correct -- Network Address Translation (NAT) boxes do this. Moreover, the use of NAT boxes allows to significantly reduce the problem of IPv4 address space depletion (as sites that use NAT boxes can use private address space out of RFC1597), so that we wouldn't run out of IPv4 addresses any time soon. Yakov.
participants (6)
-
bmanning＠ISI.EDU -
davids＠on-ramp.ior.com -
jon＠branch.com -
owen＠DeLong.SJ.CA.US -
Ruediger Volk -
Yakov Rekhter