On Fri, Sep 21, 2012 at 10:16 AM, Usman Latif <[email protected]> wrote:
> Thanks for the feedback. > I just want to confirm something. > > You wrote: > "If you choose to do this, it is further recommended that you reserve the > entire /64 so that - if needed in the future - you can expand this > configuration _without_ a major renumbering event." > > This is the essence of what I want the IETF to put in one of its address > recommendation RFCs because I have yet to see an RFC that says when you > assign a /127 to a p2p link, you should/must reserve the whole parent /64 > for that p2p link also. > > Without this stated clearly there is likely to be some instances where > readers interpret it the wrong way and end up assigning multiple p2p links > with /127 subnets from a single given /64 and end up having to re-address > their network in future when/if future standards use lower order 64 bits > for special purposes. > Right, each PtP link should have it's own /64 assigned. It should also be so-configured, but if you choose to alter that something else (e.g. - a /127) may be configured. But with that specific /64 still reserved per PtP link! > Also you didn't talk about loopbacks at all. > > IMO any single loopback although a /128 should also have the whole parent > /64 assigned to it because the issues with not doing that are pretty much > the same as for p2p links > Correct, in fact - I intentionally excluded them :). I would say a single /64 per site (or whatever demarcation / term you choose to use) should be reserved for the purpose of assigning /128s to loopbacks. Not a /64 per loopback, a /64 per ~site to cover all of the loopbacks within that ~site. *I presume 18BB loopback addresses per ~site is sufficient? ;)* /TJ
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
