On 7 nov 2007, at 1:08, Robin Whittle wrote:
I am the only person to have attempted a comparison or critique of of the proposals. I haven't yet compared TRRP with the others. It is nearly 4 months since my Ivip proposal became available as an Internet Draft
Can you send me the latest version of your draft (or a link) in private email?
- and 3 weeks since I proposed a solution to the PMTUD problems faced by all these ITR-ETR proposals:
http://www.firstpr.com.au/ip/ivip/pmtud-frag/
I only scanned this quickly (it's a bit long...), but it looks like a complex scheme in the same vain as Fred's MTU proposals. In my opinion, that's not the best way to handle this. First of all, operators need to make sure that they use decent MTUs after tunneling so that hosts that send 1500-byte packets won't get in trouble or lead to much, if any, MTU discovery. Second, tunnel endpoints should simply implement two sides of path MTU discovery: they should discover the maximum packets they can successfully send to the other endpoint, and they should set their own inbound MTU to that value minus the size of the header that's added. This is simple enough that it's possible to get it right and doesn't add much overhead.
I know the "crisis in routing and addressing" stuff we are working on relates largely to scalability of the BGP routing system, and is not explicitly tied to IPv4 address depletion, but I am adamant that:
1 - IPv4 address depletion is the most urgent architectural problem facing the Internet - and far better recognised than BGP stability and router scaling problems with the growth of advertised prefixes.
Ah, but that's a solved problem. RRG = research, IETF = engineering. IPv4 depletion = operation. We all know what needs to be done here. A wise man once said: just do it.
2 - All the ITR-ETR schemes are capable of slicing and dicing IPv4 address space in many more pieces, and in finer pieces, than is ever likely to be practical with BGP.
3 - Therefore, any of the ITR-ETR schemes could make a major contribution to the more efficient utilisation of IPv4 space.
I'm not convinced. The issue isn't the number of places that need an address block, but the number of places that need an individual address.
4 - We are stuck with IPv4 for the next decade or so. IPv6 provides few, if any, benefits for ordinary end-users, is complex and is not ubiquitously supported by applications, firewalls etc. No ordinary Internet user is likely to be happy with an IPv6-only address in the foreseeable future.
The alternative is NAT, which is worse.
5 - IPv4 address space utilisation could easily be improved if there were suitable policies and slicing and dicing technologies. Ping responsive host rates in advertised space are around 4%:
Meaningless. First of all, they also pinged unrouted space. Second, current Windows doesn't respond to pings. Third, there's NATs and firewalls. Fourth, not all systems are turned on 24/7. Fifth, this is an average that includes both stuff given out under the current fairly tight policies and large amounts of stuff given away to people who aren't using it anymore.
So there is plenty of room for improvement.
No. Any effort spent on getting back IPv4 space for new uses is wasted effort, because we need to move to IPv6 in the slightly longer run anyway.
We are attempting to devise something really challenging here - and I think more expertise, more energy and wider perspectives would be very helpful.
Again: no. We made our beds over the past 15 years. We have another few years to fluff the pillows, then it's time to go to sleep. Even if it's possible to go back and redo the IPv6 effort and arrive at substantially better results (debatable), it's too late for that now. The message should be: you have three more years to start running IPv6 if you don't want to be left behind on a network that isn't going anywhere in the medium- to long term.
-- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
