Pekka, et al, >> 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."
seems to me that we're trying to engineer a solution to a problem which we _think_ may exist, but only because we don't trust the ISPs to do the right thing. the IETF has already given the recommendation that each user should get a /48, as long as we make protocols, so that it is a cheap to delegate a /48 as a /64 we've done out job. the market should sort the rest out. if that turns out to be wrong, then we have enough alternatives we can work on then. - ND proxy - RA proxy - MLSR - bridging - longer prefixes than /64 - NAT - ... /ot -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
