<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>Hi Kai,</div><div><br></div><blockquote type="cite"><div><span>So, since anything _above_ /64 (e. g. /65 to /128) would be whitewashed by the proposal, using a whole /48 PA or PI for /64s for WiFis would be ok, as long as each WiFi user only gets less than a /64 »assigned«?</span><br></div></blockquote><div><br></div><div>That's what the proposal currently says. </div><br><blockquote type="cite"><div><span></span><span>Proposal states: »Today, organisation networks usually include some kind of guest networks, (public) WIFI hotspots in their offices, PTP-VPN links to customers’ sites, or anything similar where devices of non-members of the organisation would get assigned an IP out of the organisation’s prefix.«</span><br><span></span><br><span>These days I configure P2P links as /64 (with ::1 and ::2 being the endpoints), because ... people actually tried to hit me with cluebats when I carried over IPv4-behaviour of /32 or /31 links into IPv6 (/127). </span></div></blockquote><div><br></div><div>Actually, using a /127 for point to point links is pretty common. There is even an RFC about it (<a href="https://tools.ietf.org/html/rfc6164">https://tools.ietf.org/html/rfc6164</a>). I use it a lot, also I the training courses I give. I reserve the whole /64 in the numbering plan just in case, but on the link I usually configure ::a/127 and ::b/127. </div><br><blockquote type="cite"><div><span>So, even after this proposal, I am not allowed to use my IPv6 PA or PI space to build P2P-links outside my organisation, e. g. for peering, with a netmask of /64? But at least anything above /64 (read: /127) in PI would be ok, which currently isn't, neither for PA nor PI?</span><br></div></blockquote><br><div>Technically, yes. I still have to re-read the PA bit, because I'm not sure about that. I'll reply to that later.</div><div><br></div><div>Cheers,</div><div>Sander</div><div><br></div></body></html>