On Wed, 24 Mar 2004, Erik Nordmark wrote: > First of all, based on RFC 3177 an ISP needs to be capable of handing of > /48 prefixes to customers. The issue here is when the ISP doesn't do that.
Precisely. [...] > I think this assumption is false. An router does not need to advertise an > on-link prefix for the link between it and the client. > The client machine does need to be able to allocate an IP address > which is easy without an on-link prefix when using DHCPv6, > and a bit more subtle using stateless address autoconfiguration. > (The issue is how the host autoconfiguring an address effects the routing > on the ISP side.) Stateless address autoconfig mode you're talking about is about advertising a /64 prefix on the link, with addrconfig flag set, and onlink flag not set --right? While the onlink flag gives no information how the hosts could communicate between themselves, it still gives the ability to connect multiple hosts on a link -- so it cannot be used by the ISPs to force "1 user/prefix" -model, right? So, this doesn't seem to have practical benefits to just advertising a /64 on the link. (The difference is just that without on-link flag, the hosts should communicate between themselves through the default router.) > Thus I think the ISP that wants to charge differently for one IPv6 address > per customer compared to a /64 or /48 prefix can do this as easily as it > can in IPv4. I don't know how this relates to the above, but this seems obvious. The point, however, is whether that /64 is really restricted to that link or not. I.e., whether this is a weak form of "one host only" model or not. (Assuming the subnet can't be extended, the customer can't use his own proxies, firewalls, or the like, but would have to plug all the devices in parallel.) > This implies that ISPs that want to hand out /64 or /48 prefixes > should use an explicit prefix delegation mechanism which explicitly > delegates the prefix to the customer and not implicitly does this > by assigning a /64 to the link between the ISP and the customer. This is indeed a "should". But the point is -- do we want to provide a solution for the case where this "should" does not hold? Note that the ND-proxy case is rather strong in 3GPP environments as well: the nodes are given a /64 per PDP context. If you want to hook up your laptop to your mobile (which has v6 PDP context), the mobile either has to do ND proxying, or you'll have to open a new PDP context on your laptop (e.g., of PPP type). And those 3GPP guys always start screaming when you want to open more PDP contexts.. :) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
