This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/address-policy-wg@ripe.net/
[address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification)
- Previous message (by thread): [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification)
- Next message (by thread): [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Kai 'wusel' Siering
wusel+ml at uu.org
Sun Oct 23 01:07:54 CEST 2016
Moin, just a quick reply as well. Am 22.10.2016 um 23:30 schrieb Sander Steffann: > >> Let's play it through: The policy change gets approved and implemented, and now a /64 of my IPv6 PI for my WiFi is ok. (And giving a /64 or less to my kids/neighbour/barber is as well?) But, I actually operate two WiFis, one for the general public and one for my family. Thus, I now use a /63 in total, but only a /64 each, for WiFi. Ok, not ok?Ok, as: »Within the context of these policies, a sub-assignment is an assignment of a length of /64 or shorter.« >> >> (Actually, it would not be ok, as »/64 or shorter« still prohibts use of /64 for e. g. WiFi. The proposal therefore should read »/63 or shorter« or »shorter than /64«, I think, or SLAAC is not an option anymore.) > You are misunderstanding. We're not talking about what you configure on your Wi-Fi, we're talking about what you delegate to third parties: the users of the Wi-Fi. Unless you assign a whole /64 to a single Wi-Fi user it's within the proposed policy. Bear with me; I still cannot accept the conflicting-with-policy definition of »delegate« or »assign« in the context of RA or DHCPv6. Proposal states: »As an example, some Freifunk Communities in Germany have been had their PI request declined because some 1-digit-number of subnets would have been used as IPv6 prefixes on public WIFIs. This usage of the IP space in the End User’s infrastructure has been interpreted as a sub-assignment of a /128 prefix. This would have been "assigned" to a user device of the public WIFI network as the device would get an IP address via SLAAC (or any other means for that matter).« 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«? 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.« 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). 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? Regards, -kai
- Previous message (by thread): [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification)
- Next message (by thread): [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]