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/[email protected]/
[address-policy-wg] 2016-04 Review Phase (IPv6 PI Sub-assignment Clarification)
- Previous message (by thread): [address-policy-wg] 2016-04 Review Phase (IPv6 PI Sub-assignment Clarification)
- Next message (by thread): [address-policy-wg] 2016-04 Review Phase: Draft Document and Impact Analysis Published (IPv6 PI Sub-assignment Clarification)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Maximilian Wilhelm
max at rfc2324.org
Tue Jan 10 18:58:24 CET 2017
Anno domini 2017 JORDI PALET MARTINEZ scripsit: > Fully agree. I’ve also expressed my concern about this being the wrong way. > I’ve also discussed in private with the author regarding several issues, including how wrong is having a text that mention something like /80. From RFC7136: [...] So, for shooting myself into my own foot (to steal your wording): I'm inclined to agree with you. After reading the IA I'm unsure wether the prefix length approach is leading to the best solution of this problem. I thought on this a while and basicly came up with similar ideas to yours but had a hard time putting it into words. So whatever journey this proposal will have from here on, at least we got into a discussion about an issue we at least can agree on exists. :) > Now, what happens if the assignment is not /64, but several /64 for each “machine”, as being suggested by new IETF work? > > For example, the servers and employee computers in a company that has received a /48 IPv6 PI, will be in this case. They may decide to allocate a single /64 for each VLAN (computers may be from the company or from employees, such as cellular phones, tablets, laptops), but maybe they prefer to allocate a /64 for each computer … and may be in the future several /64 for each computer, because they are running virtual machines in different VLANs. > > I suggested several options, for example trying to adjust the definition of “infrastructure”, “assign”, or even other choices such as: > > The PI assignment cannot be further assigned to other organisations. An exception to this will be managed services to third parties or point to point links, using the PI owner, own managed infrastructure; in that case, will not be subjected to registration, and it will not be considered as a sub-assignment, regardless size of the addressing space being used for those services (from a single address to multiple /64). An example of this will be a company offering managed networking services to SMEs to connect user-devices or even servers, such as: Users in public hot spots, employees or guest SSIDs or VPNs or VLANs or LAN segments in organizations, servers in a data centre. (SMEs are Small and medium-sized enterprises?) That would be something I'd be rather fine with. It solves the problems people faced in a more general way. I opens up some use cases and scenarios - which I tried to avoid to keep the scope of this discussion limited - but might be a nifty solution to clear these problems once and for all. This will however touch the PI/PA question as it opens up the usage of PI space for hosting providers and the like which I was trying to avoid, too. > or > > Within the context of this policy, assignments not done to end-sites by means of point-to-point links are not considered sub-assignments. That would be bit to vague for my taste. > I know is not neither of those are perfect, and may not work, but it may be a starting point for some more discussion. > And last idea (shooting to my own foot, as original author of the IPv6 PI policy proposal) … Do we really need anymore a different rule for IPv6 PA and IPv6 PI ???? That in particular was a subject I tried to avoid touching ;-) Best Max -- "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mahatma Gandhi
- Previous message (by thread): [address-policy-wg] 2016-04 Review Phase (IPv6 PI Sub-assignment Clarification)
- Next message (by thread): [address-policy-wg] 2016-04 Review Phase: Draft Document and Impact Analysis Published (IPv6 PI Sub-assignment Clarification)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]