[changed subject to something more related ;) ] Brian Candler wrote: > 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.
That Internet thing is a changing place, things that are broken get fixed ;) [..] > 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. Then shout and scream in the RIPE forums and support the policy. That is the only way that it will be accepted: when the majority wants it. [..] > That is, the IPv6 tail still tries to wag the commercial dog. The Internet has been commercial for ages already, thus of course it will follow the people with the big money. But as with any kind of politics, and this is just that, the one with the biggest mouth + biggest amount of cash wins. >> 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. Which is a bad plan. Although the routing issues are not solved (yet). The addressing issue is solved with IPv6. Getting a deployed base of enduser systems that supports IPv6 is a very important factor. Otherwise you will finally have this great routing system, but nothing will actually be able to use it yet and thus you still have to wait for the endusers to upgrade; which will take ages. Deploying IPv6 now is a good thing. The core of the network will take care of the routing and any other tricks that will be needed to route the 128bit address space. Routing is the problem, not the addressing anymore. >>> 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" As I said it is only a suggestion. When a LIR gives out /56's they can do this. No RIPE police will be knocking on their doors. Also there are proposals to start using /56's. The counter argument against them though is that there are so extremely many /48's and so extremely many /32's to get them from that the point of using /56's is a little bit moot. /48's are very handy in use, as the first 4 numbers are 'theirs', the rest is yours. BTW: calculate how many /48's are in 2000::/3 and you'll get an idea. Note that when 2000::/3 is full there are 7 other 'tries' left to get it right. > 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. If that customer requires multiple /64's they should get a /48 at the moment. Note my use of SHOULD which is not a MUST. >> 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 :-) Some people like marketing and filling their pockets with government and consulting tricks, can you blame them? ;) > Therefore many of the points you make are essentially agreeing with me: IPv4 > and IPv6 are the same in many cases. Correctemundo. Except for the larger address space they are mostly the same. >>> 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. A variant of what you describe was one of the varying proposals for IPng, after which IPv6 was chosen to be 'the one'. There where proponents of variable addressing, upto 180bits, and some wanted short addresses (/64's I recall). They settled on using this model, you might recognize it: <..... provider range....> < .... client range ... > First part mostly variable, somewhere between /16 and /32, so that every provider can at least have 65k clients. The client range is fixed to a /48. Et tada, a 128bit address. No weird header addons nothing and routers can simply handle the packet in full length. As I mentioned, the addressing system is not the problem any more, there are enough addresses with IPv6. The routing system is the issue, especially with people using the routing system for traffic engineering. For your stacking idea, how do you solve this problem: Destination address: 1.1.1.1:2.2.2.2:3.3.3.3 Now I want to send a packet to it, thus I try to send my packet. The routing system notices that the link from 1.1.1.1 -> 2.2.2.2 is down though. What now? Crash burn? ICMP unreach and let the host find where it otherwise resides? The big problem with your 'design' becomes apparent here: there is no globally unique identifier thus we don't know who to talk to, or who we are talking too. There was an alternative path though over 4.4.4.4 but as you mixed addressing and routing that path can't be picked. Btw, check 3.2.5 of http://www.ip6.com/us/book/Chap3.pdf Just did a google(IPv6 Routing Header) and it popped up, seems to explain it quite well. It can thus already be done with IPv6 to force a packet over a certain route. But will ISP's in the middle adhere to that packet!? Most likely not. Also the overhead of adding/removing those kinds of stacked labels is not fun in hardware what I understood. > At the top > level, these 32-bit values would essentially be AS numbers. Kind of MPLS for > IP. This gives you extensibility and aggregation. Indeed it will nicely aggregate to 4 million routing entries. There are only ~200k entries in IPv4 routing tables and people are complaining about issues already. Especially the folks who don't want to upgrade their hardware. This schema ain't gonna work. > Whatever you feel about the evils of RFC1918 + NAT, it's here, it works well > enough, and it's cheap. Ever tried to 'merge' two banks with on each side 10.000 computers, both using RFC1918!? Feel the pain when you have to do that again ;) RFC1918 has it's uses and so does NAT, especially in places where ISP's are not cooperative and don't have to much cash. But for the rest avoid at all cost. > 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. Correct and I expect that to happen also. But you can just as well just route that RFC4193 prefix to the other network as it doesn't clash with other people's address space, like in my bank-merge example above, and THAT will save you loads of headaches. And that is the reason why RFC1918 is bad. NAT in itself is not too bad, it just breaks a lot of protocols which one needs to mangle. A double-NAT for that matter, thus one restoring the packet to it's original contents doesn't hurt anything. The best way to solve security issues is to run every protocol through a proxy anyway. Thus: local network RFC4193 space, proxy using some IP address from some ISP and one out of the local pool. Done. Does not solve the case where one actually wants to provide services of course. > 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. No the application programmer will remain unhappy as they need to fiddle to get around that NAT all the time. >>> 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. Then get PI space. That is 'get your own set of globally unique addresses'. How others can reach it is a different question. > (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. No, the /48's given out by ARIN are "PI" and don't have any such requirement. Those prefixes are assigned to one 'site'. And that is why /48's (or actually a site-size prefix) are so nice, if you start out with a block from an ISP, you make your network design in that /48. Later you get your own PI block, your network design remains valid, the renumbering pain and hassle thus mostly remains at contacting and reconfiguring external parties. Internally one can relatively easily renumber. > 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. Those are just artificial barriers put in place in most of the current policies. Most ISP's and transits who have filtering in place accept prefixes upto /48's without question. Quite a moot point thus. Greets, Jeroen [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
