Re: ND-proxy applicability and loop-prevention

[Ole Troan <ot@xxxxxxxxx>]

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
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------