On Mon, 29 Mar 2004, Erik Nordmark wrote: > > > - it is too hard for them to explicitly delegate prefixes > > > > Note that this is not a binary decision, i.e., the ISP might decide > > that "OK, it's not too hard for us to delegate the prefixes, but if we > > do that, we want some extra payment from the user for the trouble". > > So then you end up with a single IPv6 address, right?
Not necessarily. If you don't run something like PPPv6 on the link to the customer, just advertising a /64 on the customer link seems to be the simplest thing the ISP can do. (Even simpler than just a single IPv6 address.) Without ND-proxy or bridging, that's one IPv6 address. > > In that kind of environment, ensuring that the users have tools to > > cope with a /64 prefix as well would seem to be really important. > > But the /64 isn't delegated to the subscriber - it is merely assigned > to the link between ISP and the subscriber. Sure, but with ND-proxy this distinction is irrelevant, which was the the point to begin with. > I think RFC 3177 is quite clear on its recommendation. > Why can't we simplify the message and avoid developping additional protocols > (which are as likely to slow down IPv6 deployment as speeding it up) by saying > that ISPs which don't delegate at least a /64 (using a protocol/mechanism > which delegates it to the *subscriber* and not just assigning it to the link > from the ISP and the subscriber) doesn't follow the implications of the > recommendation in 3177? The problem is that with the same trouble it takes to fully delegate a /64, the ISP could do a /48 as well. That is a good thing also, of course. My worry is that the ISPs end up doing nothing unless they have simple enough means available. I mean, the message could also be "just give every customer a delegated /48. If that is not possible, advertising a /64 on the link is better than nothing." This takes no stance on the other "subnet extending" scenarios where ND-proxy could be desirable, like a gadget on firewire connected to your PC. -- 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 --------------------------------------------------------------------
