Keyboard Shortcuts
Thread View
j: Next unread messagek: Previous unread messagej a: Jump to all threadsj l: Jump to MailingList overview
Hi Folks,
I just got through reviewing your Internet Draft on 240/4 and we had considered a different path in mind for this prefix with a draft prepared to give it a slightly different meaning ;).
We were curious what you thought of allocating 240/4 to public duty for IANA assignment and future public global use. Why do you feel this should be RFC1918 address space instead of allocating it for wider Internet use?
Clearly there would be operational hurdles and challenges to consider towards updating filters, code, and possible other nooks and crannies but the net result and added lifetime for v4 might be worth the effort.
Looking at the recent allocation history we've seen:
2007 8 /8's (9 minus 1 re-listed as reserved)
2006 10 /8's
2005 13 /8's
2004 9 /8's
So this could possibly give us an additional 1-2 years of IPv4 lifetime (hopefully more as the end nears). This would bring the current aggregate number of /8's from roughly 44 to 60 available, an increase of approximately 36% allocatable /8's.
Does the need for more private addressing outweigh the need for more public addressing? At a minimum it would be great to add a paragraph addressing this important question.
Thoughts?
Stephen,
In order to take advantage of 240/4, new code will have to be deployed and there are systems that cannot/will not be upgraded. While an organization receiving a block out of 240/4 could conceivably guarantee none of their systems dropped 240/4 on the floor, it is a bit unlikely that the rest of the Internet could be trusted to behave similarly. As such, people who received 240/4 blocks would likely be quite unhappy.
If people are going to use 240/4, it'll have be done "among consenting adults".
Rgds, -drc
On Aug 7, 2007, at 11:43 AM, Stephen Gill wrote:
Hi Folks,
I just got through reviewing your Internet Draft on 240/4 and we had considered a different path in mind for this prefix with a draft prepared to give it a slightly different meaning ;).
We were curious what you thought of allocating 240/4 to public duty for IANA assignment and future public global use. Why do you feel this should be RFC1918 address space instead of allocating it for wider Internet use?
Clearly there would be operational hurdles and challenges to consider towards updating filters, code, and possible other nooks and crannies but the net result and added lifetime for v4 might be worth the effort.
Looking at the recent allocation history we've seen:
2007 8 /8's (9 minus 1 re-listed as reserved)
2006 10 /8's
2005 13 /8's
2004 9 /8's
So this could possibly give us an additional 1-2 years of IPv4 lifetime (hopefully more as the end nears). This would bring the current aggregate number of /8's from roughly 44 to 60 available, an increase of approximately 36% allocatable /8's.
Does the need for more private addressing outweigh the need for more public addressing? At a minimum it would be great to add a paragraph addressing this important question.
Thoughts?
-- Stephen Gill, Research Fellow, Team Cymru http://www.cymru.com | +1 312 924 4023 | gillsr@cymru.com
sig-policy: APNIC SIG on resource managementpolicy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Hi David,
In order to take advantage of 240/4, new code will have to be deployed and there are systems that cannot/will not be upgraded.
Do you have some sense as to what those systems are, code versions, and how many? I know it is on the list of Juniper martians for instance.
While an organization receiving a block out of 240/4 could conceivably guarantee none of their systems dropped 240/4 on the floor, it is a bit unlikely that the rest of the Internet could be trusted to behave similarly. As such, people who received 240/4 blocks would likely be quite unhappy.
I see this as a similar challenge to what we have today, with an added systems component. Certain entities with newly allocated prefixes have already experienced reachability issues with their allocations due to stale or outdated filters. This was largely overcome with a bit of operational planning and foresight.
At some level I could envision something similar for 240/4 whereby it could be allocated and de-classified as a bogon, and then tested for reachability using pilot/anchor prefixes after "sufficient" time has been given for vendors and operators to implement the change. Ongoing reachability testing (active and passive) could be performed from the newly debogonized ranges to see how reachability compares to previously allocated /8s in recent past. Granted, it would take some time, testing, and planning but is it not conceivable that reachability could be attained to similar levels as that of a normal newly allocated, de-bogonized /8?
It seems worth considering if possible systems issues can be overcome with enough time given for planning if it extends the life of IPv4 by a reasonable amount. It would also be useful to put those considerations into the draft whatever the final concensus ends up being.
-- steve
Hi,
On Aug 7, 2007, at 2:48 PM, Stephen Gill wrote:
In order to take advantage of 240/4, new code will have to be deployed and there are systems that cannot/will not be upgraded.
Do you have some sense as to what those systems are, code versions, and how many? I know it is on the list of Juniper martians for instance.
As far as I'm aware, pretty much every version of every operating system out there (including Windows, MacOSX, Linux, etc) doesn't allow configuring 240/4. Whether or not those OSes are upgradeable depends on many factors, of course. E.g., I don't think Microsoft will be supplying a patch for Windows NT/98/etc.
And then there are the embedded systems.
The point is, this is a change of rules way late in the game in terms of software deployment and backwards compatibility is of high importance to folks trying to sell services on the address space allocated.
Granted, it would take some time, testing, and planning but is it not conceivable that reachability could be attained to similar levels as that of a normal newly allocated, de-bogonized /8?
I'd be very surprised that the amount of time necessary to sufficiently untaint a 240/4 block would be less than the amount of time necessary to have significant IPv6 deployment.
It seems worth considering if possible systems issues can be overcome with enough time given for planning if it extends the life of IPv4 by a reasonable amount. It would also be useful to put those considerations into the draft whatever the final concensus ends up being.
This was discussed, but the decision was to opt for brevity in the document.
Rgds, -drc
Hi David,
As far as I'm aware, pretty much every version of every operating system out there (including Windows, MacOSX, Linux, etc) doesn't allow configuring 240/4.
That being the case it's certainly thornier than I anticipated. I believe some of those fare better than others, but if you can't even route to a prefix for backwards compatibility from a system I tend to agree it's likely more of an uphill battle. I would have expected reachability to differ from configurability (inet, routing) on the Windows platform, but they appear to go hand-in-hand.
The point is, this is a change of rules way late in the game in terms of software deployment and backwards compatibility is of high importance to folks trying to sell services on the address space allocated.
Fair point. Although one could argue that v6 is another reachability step removed from that with regards to v4 hosts, and the systems that can't be patched/upgraded would need a dual stack anyways.
[ ... ]
From Paul Wilson's note:
The benefit of private space is that each address can be used many times. Therefore the additional 16 blocks of private space proposed here could satisfy the need of a very large number of very large private networks, without consuming a single public address.
Understood. My impression was that public allocation requests were largely because public addresses are needed, not because RFC 1918 private addressing wasn't sufficient. In virtually all cases I've seen where RFC 1918 wasn't sufficient, it was due to poor planning or implementation. Read: allocating much more internal space than necessary despite possible future needs for growth. This was usually a simple fix w/o the added need for public addresses.
I've not witnessed the lack of private use addresses to be much of problem, but perhaps a portion of public allocations are requested because of poor internal private address planning. I suppose adding 240/4 to the available private pool could alleviate some of this assuming they are willing to go through the "pain" of being systems ready. It would be useful to have some idea as to how much this will really help long term.
On the other hand, if the space is redesignated as standard public unicast, then it can be used once only. At today's rate of consumption, this would add a year or so to the lifetime of IPv4. Add to this the greater difficulty of transitioning the entire Internet to deal correctly with 240/4 addresses (which is likened to the challenge of IPv6 transition), and I suggest the only viable alternative is private.
I think the added lifetime may be underestimated a bit as resources continue to become more scarce and the value of IPv4 commodities rise, but those are all certainly very valid points.
-- steve
David and Stephen,
David Conrad wrote: As far as I'm aware, pretty much every version of every operating system out there (including Windows, MacOSX, Linux, etc) doesn't allow configuring 240/4.
Including IOS too (at least the last time I have checked).
Stephen Gill wrote: That being the case it's certainly thornier than I anticipated.
Also, please keep in mind that vendors are not charities, they will likely not release the new code for older platforms, and I would hate a proposal to use 240/4 (regardless if it's for public or private addresses) to become a de-facto excuse for "you have to upgrade to the latest OS" or "you have to upgrade to the latest router", or both.
Michel.
Steve,
The benefit of private space is that each address can be used many times. Therefore the additional 16 blocks of private space proposed here could satisfy the need of a very large number of very large private networks, without consuming a single public address.
On the other hand, if the space is redesignated as standard public unicast, then it can be used once only. At today's rate of consumption, this would add a year or so to the lifetime of IPv4. Add to this the greater difficulty of transitioning the entire Internet to deal correctly with 240/4 addresses (which is likened to the challenge of IPv6 transition), and I suggest the only viable alternative is private.
Paul.
--On Tuesday, 7 August 2007 2:48 PM -0700 Stephen Gill gillsr@cymru.com wrote:
Hi David,
In order to take advantage of 240/4, new code will have to be deployed and there are systems that cannot/will not be upgraded.
Do you have some sense as to what those systems are, code versions, and how many? I know it is on the list of Juniper martians for instance.
While an organization receiving a block out of 240/4 could conceivably guarantee none of their systems dropped 240/4 on the floor, it is a bit unlikely that the rest of the Internet could be trusted to behave similarly. As such, people who received 240/4 blocks would likely be quite unhappy.
I see this as a similar challenge to what we have today, with an added systems component. Certain entities with newly allocated prefixes have already experienced reachability issues with their allocations due to stale or outdated filters. This was largely overcome with a bit of operational planning and foresight.
At some level I could envision something similar for 240/4 whereby it could be allocated and de-classified as a bogon, and then tested for reachability using pilot/anchor prefixes after "sufficient" time has been given for vendors and operators to implement the change. Ongoing reachability testing (active and passive) could be performed from the newly debogonized ranges to see how reachability compares to previously allocated /8s in recent past. Granted, it would take some time, testing, and planning but is it not conceivable that reachability could be attained to similar levels as that of a normal newly allocated, de-bogonized /8?
It seems worth considering if possible systems issues can be overcome with enough time given for planning if it extends the life of IPv4 by a reasonable amount. It would also be useful to put those considerations into the draft whatever the final concensus ends up being.
-- steve
________________________________________________________________________ Paul Wilson email: pwilson@apnic.net Director General, APNIC sip: apnic@voip.apnic.net http://www.apnic.net phone: +61 7 3858 3100
Stephen Gill wrote: Why do you feel this should be RFC1918 address space instead of allocating it for wider Internet use?
For the common good, it is clear that allocating 240/4 to public duty would be preferable. However, people assigned class E address would be second-class netizens because there are and will be for a long time a large number of hosts incapable of communicating with them. De-bogonization is easy (especially when one uses Team Cymru's feed ;-) rewriting IP stacks is hard and won't happen for older OSes and embedded.
Allocating 240/4 to and extended RFC1918 would put these new addresses in the hands of large organizations. Supposedly the damage would be limited to people who have made the conscious decision of using the newly available class E.
Unfortunately, there is even more room for abuse here, as large providers short on addresses would be handling 240/4 behind NAT. I already get a 10.net address on my 3G AT&T phone; I'd rather not have to deal with a 240 address instead of the 10.
Although I did in the past write and support proposals to re-allocate class E to unicast, I now oppose these proposals. Too much trouble for too little gain.
Michel.
Hello Stephen
Apologies for this late reply.
The challenge of making 240/4 useful for global unicast has been compared with the challenge of deploying IPv6; it would involve similar publicity and deployment efforts, which are probably infeasible within the timeframe of the remaining IPv4 address pool.
In my mind this is a pragmatic choice in favour of an option which has a good chance of becoming useful within a practical timeframe, with benefits which are significant, but without involving the widespread costs of the alternative.
Paul.
--On 7 August 2007 11:43:12 AM -0700 Stephen Gill gillsr@cymru.com wrote:
Hi Folks,
I just got through reviewing your Internet Draft on 240/4 and we had considered a different path in mind for this prefix with a draft prepared to give it a slightly different meaning ;).
We were curious what you thought of allocating 240/4 to public duty for IANA assignment and future public global use. Why do you feel this should be RFC1918 address space instead of allocating it for wider Internet use?
Clearly there would be operational hurdles and challenges to consider towards updating filters, code, and possible other nooks and crannies but the net result and added lifetime for v4 might be worth the effort.
Looking at the recent allocation history we've seen:
2007 8 /8's (9 minus 1 re-listed as reserved)
2006 10 /8's
2005 13 /8's
2004 9 /8's
So this could possibly give us an additional 1-2 years of IPv4 lifetime (hopefully more as the end nears). This would bring the current aggregate number of /8's from roughly 44 to 60 available, an increase of approximately 36% allocatable /8's.
Does the need for more private addressing outweigh the need for more public addressing? At a minimum it would be great to add a paragraph addressing this important question.
Thoughts?
-- Stephen Gill, Research Fellow, Team Cymru http://www.cymru.com | +1 312 924 4023 | gillsr@cymru.com
________________________________________________________________________ Paul Wilson, Director-General, APNIC dg@apnic.net http://www.apnic.net ph/fx +61 7 3858 3100/99
Activity Summary
- 5940 days inactive
- 5940 days old
- sig-policy@lists.apnic.net
- 4 participants
- 8 comments