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] 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 ]
Jan Ingvoldstad
frettled at gmail.com
Tue Oct 1 09:35:16 CEST 2013
On Mon, Sep 30, 2013 at 3:33 PM, Elvis Velea <elvis at velea.eu> wrote: > Hi again Jan, :-) Hi again, Elvis, and thanks for your responses. … The scope of the policy has not been changed. In the current policy > assignments lower than a /64 are not permitted. Therefore, nothing is > changed. > > > >> Section 1, 1.1 Overview has this current sentence that is removed in the >> proposal: >> >> "All bits to the left of /64 are in scope." >> >> In one of the previous posts, making things easier for e.g. using >> separate IP addresses for SSL is an argument for this proposal, but as I >> read it right now, I would have to sub-allocate a /64 for each SSL >> certificate, rather than say a /128. >> >> I feel reasonably sure that this is not the intention of the authors. >> > > You are right, it was not our intention to remove that line from section > 1.1. However, even with the old policy, my understanding was that you > should have assigned a /64 for the SSL certificate and not a /128. > Uhm, no, that would be – and sorry for the strong word use here – insane. What you're essentially saying is that for any case where one would create a reverse pointer, there would have to be a /64. This does not scale at all. In terms of routing, it currently makes sense to ensure that address space smaller than a /64 is not announced globally via BGP. But preventing actual _use_ of smaller address space is a very bad idea. One of the HUGE gains of IPv6 is that you can easily encode more information in the IP address itself than you could with IPv4. There is an enormous amount of flexibility thanks to the 128-bit size of the address space. Also, if the rightmost /64 cannot ever be used, then IPv6 should've been a 64-bit address space, and I don't think policing this here is relevant. > > I am not sure that removing that line makes any difference, let's see what > the others think and we could add it back if it really changes the policy > scope. > >From a n00b's point of view, the old policy reads something like this, in brief: "This policy does not apply to address space smaller than /64" And the old policy reads: "This policy applies to address space regardless of its size" 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, and having to use e.g. 2a01:5b40:88:cafe::1/64. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: </ripe/mail/archives/address-policy-wg/attachments/20131001/7cf345f8/attachment.html>
- 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 ]