At Mon, 23 Feb 2009 17:50:03 +0100, Alexandru Petrescu <alexandru.petre...@gmail.com> wrote:
> >> But this means I couldn't accommodate the situation with two distinct > >> PIO prefixes in the RA either (/48 A=0 L=1, /64 A=1 L=0), because the > >> /48 L=1 prefix would still fool Y to believe 2001:db8:1111:cc00::2 were > >> on link. > > > > In this case A (or B) normally only advertises 2001:db8:1111::/64 with > > L=1 and A=1, and everything works just fine. The example I gave was > > to show that one of your suggested justification for the "hypothetical > > extension" doesn't work in some cases. > > YEs, it wouldn't work, and for the same reason putting /48 with L=1 > would break the same example that the hypotethical extension breaks. Of course not, but what are you trying to indicate by saying so? Actually, I'm not sure if we're on the same page. I've never suggested the use of /48 with L=1 in this usage example. The context I mentioned this tricky setting is as follows: At Wed, 18 Feb 2009 12:30:31 -0800, JINMEI Tatuya <jinmei_tat...@isc.org> wrote: > > Why should I put a /64 in the RA when that link is adminsitratively > > assigned a /56. > > If your goal is to use a /56 as an on-link prefix while using > stateless autoconfiguration, you can do it without changing the > standard by advertising: > > - prefix P::/56 with L=1, A=0, and > - prefix P::/64 with L=0, A=1 > > if the receiving host is fully compliant with RFC4861 and 4862. you didn't explain any details about the network configuration at that point, and my assumption (based on "link is administratively assigned a /56") here was that no other subprefixes matching P::/56 are used elsewhere. On the other hand, what I've been questioning in the latest messages was that the following cannot work as justification for the hypothetical extension of SLAAC with /64 IID + a shorter prefix: At Thu, 19 Feb 2009 00:15:48 +0100, Alexandru Petrescu <alexandru.petre...@gmail.com> wrote: > DHCPv6 PD power: allow a Prefix Delegation scheme to re-delegate further > (a /56 out of a /52 out of a /48) without each router needing to reserve > a /64 for its own links. This is nothing to do with the P::/54 trick in the former scenario (/48 is not assigned to "a link", but some "site", neither are /52, /56.) --- JINMEI, Tatuya Internet Systems Consortium, Inc. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
