On Mon, Jan 29, 2007 at 04:09:41PM +0000, Jeroen Massar wrote: > >> 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.
But surely, if LIR's feel it is necessary to make smaller allocations than /48's, it's a tacit admission that this supposedly near-infinite IPv6 space is *already* under pressure. I think you're right in one sense: /48 end-user allocations are stupid. With 128 bits of address space, you could give most end users a /112, which would still be the equivalent of a whole class B in the current Internet. But the current IPv6 design is broken. > BTW: calculate how many /48's are in 2000::/3 and you'll get an idea. France Telecom got a /19. Does this mean they have a plan to connect 2^29 (over 500 million) customers in the next two years? I don't think so. Making your network aggregatable means having a lot of address sparseness, and therefore a large amount of wastage. The attitude which says "I'll allocate a /32 here, rather than the /39 I actually need, because the boundary is easier to see and type" compounds this problem by orders of magnitude. > > 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. Well, any protocol which has separate control and data connections will require application layer gateway magic at the firewall, even without NAT, since the firewall has to open new [src,srcport,dst,dstport] tuples in response to requests negotiated down the control connection, and therefore it has to fully parse and understand the control messages. Adding support for NAT is only a small extra bit of work. Some would argue that all firewalls should be application layer gateways anyway. Do I want my clients talking HTTP directly, packet-by-packet, to untrusted servers on the Internet? Or should the firewall take a HTTP request, forward it, accept and validate the whole response, passing it in sanitised form back to the client? The former leaves the clients vulnerable to all sorts of attacks from malicious servers. The latter allows the firewall to validate data. As a side effect it can also give an audit log of activity at layer 7, which many companies require for compliance reasons anyway. Regards, Brian.
