On Sun, Jan 28, 2007 at 03:17:14PM +0000, Jeroen Massar wrote: > > And if you need to change ISP, and > > therefore get a new address allocation, many people would rather just put in > > some NAT at the border than take the pain of network renumbering (which IPv6 > > doesn't make any easier than IPv4) > > Depends on the size of your network of course. But you can actually get > IPv6 PI space already, you will have to cash out a bit for it, just like > for IPv4 address space, but it is there. Problem for that solved. Same > non-scaling solution as in IPv4. No differences there. > > And otherwise read RFC4193 to get your unique local goo for free.
I'll freely admit I've not been following every micro-level change to IPv6 over the last couple of years, nor every RIR policy. I wrote my notes in 2004, a year before RFC4193 came out. The RIR which affects me is RIPE. Its current policy (Sep 2006) is here: http://www.ripe.net/ripe/docs/ipv6policy.html which appears to be driven by RFC3177. Point 2.9 does define an "end site" in such a way that someone who gains PI space would not be affected by the document, since they would by definition not be an "end site". That leaves scope open for a separate PI policy. But 5.1.1 makes it clear that you won't get an allocation from RIPE under this policy unless you are an ISP. So the only other place you can go for your addresses is your provider. Now, there is a proposal for modifying this policy to allow PI allocations: http://www.ripe.net/ripe/policies/proposals/2006-02.html but as far as I can tell this is still just a proposal. Of course, other RIRs can have different policies. I did some searching around as you suggested, and I find that ARIN has now started allocating IPv6 PI space for anyone who is eligible for IPv4 PI space under their current policy. Some interesting observations have been made: e.g. http://www.bgpexpert.com/article.php?id=107 "One reason cited for moving ahead with a known problematic solution for multihoming was the statement by some organizations that they wouldn't adopt IPv6 in the absence of a multihoming solution." That is, the IPv6 tail still tries to wag the commercial dog. > Of course if you have better ideas, you can always bring it up on the > various RIR forums. I'm afraid my "better idea" is to abandon IPv6 as still-born, and stick with IPv4 until we have a new protocol which addresses more of the problems of the Internet today. > > If IPv6 had stuck > > with DHCP, which everyone knows and understands, then you could just give > > each customer a /96, rather than a /48 as demanded by IPv6, and we would > > have addresses for aeons. Not so now. > > There is *NO* demand from anyone for giving /48's to customers. It is > only a suggestion. Talking again about RIPE policy, section 5.4.1 requires /48, or larger for very large subscribers. Exceptions are made to allow /64 "when it is known that one and only one subnet is needed by design", and /128 "when it is absolutely known that one and only one device is connecting" However, it is pretty hard to "know" this, short of asking each customer to sign a contract saying that they will only ever put a single LAN or single device behind the service you provide. I guess these exceptions are to permit ISPs to give out /64 or /128 on dialup ports, DSL lines or mobile phones. But the implication of this policy is that it is not feasible for a customer to have one /64 and slice it up into 2^32 /96's (for instance), because otherwise you could just give all customers a /64. That contradicts what you wrote. Same proviso about different RIR policies applies, but this is the one which affects me. > I suggest you start doing some background reading, read a good book or > something as you clearly are missing a LOT of information, as I've > easily shown by the answering the FUD you where trying to spread above. Well, I don't know what the opposite of "FUD" is called, but IPv6 afficianados have been trying to spread it for many many years :-) > To address the points in that document: > > > 1. ROUTING TABLE EXPLOSION > > IPv6 is an ADDRESSING system, it has nothing (not much at least) to do > with routing. BGP/ISIS/OSPF are ROUTING systems. Yes. The thrust of the document, which I tried to make clear in the preamble, was: what are the current problems and concerns with the IPv4 Internet? And for each problem or concern, does IPv6 do anything to improve the situation? Therefore many of the points you make are essentially agreeing with me: IPv4 and IPv6 are the same in many cases. > > 3. THE MULTI-HOMING PROBLEM > > See 1) Same problem in effect. > > Btw, phone numbers are analogous to DNS, not to IP addresses. Yes. So in a *real* solution to the problems of IPv4, maybe you make IP addresses look more like DNS names. Random thought: consider something like IP "header stuffing". Each network, within their own domain, assigns 32-bit addresses however they see fit. When their traffic enters another domain, it has a new 32-bit address stuffed onto the front which is unique within the enclosing domain. At the top level, these 32-bit values would essentially be AS numbers. Kind of MPLS for IP. This gives you extensibility and aggregation. Since addresses vary based on topology, you would need some other mechanism to bind (fixed) identities to (dynamic) network addresses. It certainly ain't IP as we know it. That's the point. And the idea outlined above quite possibly won't work at all. But new ideas can be tried out on overlay research networks, and maybe one of these will come up with something better than we have today. To a degree, I accept the pragmatic argument which says "we don't know the right solution to any of these problems, so let's just take IPv4 and extend the address space". I just don't think that's a strong enough argument for ripping out the IPv4 Internet and replacing with something that's equally broken in every other way, even though much effort has already been expended in that direction. Whatever you feel about the evils of RFC1918 + NAT, it's here, it works well enough, and it's cheap. RFC 4193, which you raised, actually makes it attractive to keep the same architecture in an IPv6 world: give your network a private address range, and NAT at the borders. This de-couples you from any one provider, and gives you some simple multi-homing capabilities. An example of doing this using pf was posted on this list recently. (There: something relevant to misc@openbsd.org at last :-) So NAT will be deployed because it has *commercial* benefits. The IPv6 techno-utopians will continue to be unhappy. > > 6. SMALL PROVIDERS, DEVELOPING COUNTRIES > > No problem there, even when you wrote that document. ANY ISP has a plan > for 200 customers, if you don't well, is there use for you then getting > a /32 of address space? (1) A /48 may well be enough in terms of space, but the problem is that it is provider-assigned, giving both the ISP and all their customers a huge pain later on of renumbering. (2) If you only get a /48, then your customers by definition must get smaller allocations than /48, making them second-class to customers of "real" ISPs. Some of the initial rigid design of IPv6, totally divorced from commercial reality, has thankfully now gone: remember the 13-bit "top level aggregator" and 13-bit "second level aggregator"? But from a micro-ISP's point of view, it lives on in the /32 (provider) to /48 (end site) divide. Not that it matters a jot if IPv6 never rolls out. I'll get off my soap box now. Regards, Brian.
