[address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space)
- Previous message (by thread): [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space)
- Next message (by thread): [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Elvis Velea
elvis at velea.eu
Tue Oct 1 12:33:12 CEST 2013
Hi Jan, thank you for your reply and sorry for the top posting. I got your point and I will ask the RIPE NCC hostmaster to add back the sentence that we removed by mistake. For the next version we also need to decide whether: - we should be strict and restrict what you can do within a /64 - we should not care what happens within the /64, it's the decision of the address space user. This is an other point for a slide at the RIPE Meeting :-) cheers, elvis On 10/1/13 11:44 AM, Jan Ingvoldstad wrote: > On Tue, Oct 1, 2013 at 11:11 AM, Elvis Velea <elvis at velea.eu > <mailto:elvis at velea.eu>> wrote: > > Hi Jan, > > > Hello again, Elvis. :) > > I'm not talking about how much you would use on your router or > reverse dns. > > I'm talking about how much to 'reserve' as minimum for a > point-to-point link or for a service. > > > … > > > It's not preventing use of a smaller prefix, it's preventing > assigning/sub-allocating less than a /64 for anything. > > > … > > Well, I used to work as an IPRA at the RIPE NCC and my understanding > of the policy then (and now) was that assignments and/or > sub-allocations of anything below a /64 is out of scope and even if > one IPv6 address is used within a /64, the whole subnet is > considered to be used. > > > While this particular paragraph is fine, the others are less than, uhm, > clear. > > > To me, this is the difference between letting me use e.g. > 2a01:5b40::80:88:dead:beef:__cafe as the IPv6 address for > www.oyet.no <http://www.oyet.no> > <http://www.oyet.no>, and having to use e.g. > 2a01:5b40:88:cafe::1/64. > > > I don't actually see it like that. You can still use the whole IPv6 > address to number a device, it's just that you can not split a /64 > for different services. > > For example, you can use a /64 to number, let's say, 100 devices > that are in the same vlan doing the same thing and providing the > same service but you can not number 100 different customers within a > /64. > > > … because of this. > > This doesn't make sense. > > Why can I not number 100 (or indeed, hundreds of thousands of) addresses > for different websites within a /64? > > I think, perhaps, that the words "customer", "service" etc. are poorly > defined and lead to significant misunderstanding, and that I have not > made myself clear. > > Whatever a hosting provider chooses to do with their IPv6 space to > perform comparatively fine-grained routing and other network > organization, should be pretty much irrelevant, as long as what's > exposed to peers is sane. > > The example I came with is not randomly chosen, I know there has been > similar issues with the understanding of semantics in IPv4 policy, which > according to some NCC members seemed to imply that it would be > impossible to use a separate IPv4 address per SSL site without > comparatively major bureaucracy, since (the argument went) these > addresses should be assigned and registered. > > Now you seem to be telling me that I cannot have a single webserver > serving two different websites with two different IPv6 addresses, if > they are both within the same /64. > > If this is really the case, IPv6 is, within RIPE, a 64-bit address > space, not a 128-bit address space, and depletion is guaranteed to > become a problem with the proposed policy, as well as the current > policy, considering that every hosting provider would need _many_ /32 > allocations, as I understand the policy and the argument you make. > > If, however, we consider IPv6 an 128-bit address space, and the > rightmost /64 as simply not governed by RIPE policy, then a /48 is a > _humongous_ address space, providing a LIR with 65k networks which may > be redelegated to lower-level customers, such as e.g. web hosting > providers, as long as these are routed as a /64 block. > > -- > Jan
- Previous message (by thread): [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space)
- Next message (by thread): [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]