If we agree that *persistent* addresses can be provided, my opinion is that 
then it is just fine to have your machines in my infrastructure, using my 
addresses.

If you tomorrow move your machines to another place, you will not be able to 
keep using my addresses. So of course, either from day one, or when you move, 
you have the chance to get your own IPv6 PI block.

We need to consider as well, as I depicted already before, that if you have a 
physical sever, you probably need also multiple addresses for that server, 
that's why, I think the policy should allow that (this is clearly now allowed 
now).

Regards,
Jordi
 
 

-----Mensaje original-----
De: address-policy-wg <[email protected]> en nombre de Jetten 
Raymond <[email protected]>
Fecha: jueves, 17 de enero de 2019, 14:41
Para: JORDI PALET MARTINEZ <[email protected]>
CC: "[email protected]" <[email protected]>
Asunto: Re: [address-policy-wg] suggestions from the list about IPv6 
sub-assignment clarification

    # commented
    
    -----Original Message-----
    From: JORDI PALET MARTINEZ <[email protected]> 
    Sent: 17. tammikuuta 2019 15:22
    To: Jetten Raymond <[email protected]>
    Cc: [email protected]
    Subject: Re: [address-policy-wg] suggestions from the list about IPv6 
sub-assignment clarification
    
    Hi Ray,
    
    The question of the DC is much more complex. I think.
    
    For example, is the same if the "hardware" (the real servers) are from the 
assignment holder or from third parties? (hosting vs housing).
    
    I think hosting will be ok from the perspective of both the original IPv6 
PI policy and the actual one. However, housing is at least, "in the limit" of 
what was intended originally ("not to be sub-assigned to other parties ").
    
    
    
    
    #With the actual policy both are allowed, but housing seems to be allowed 
only if dynamic ("connecting a server or appliance to an assignment holder's 
network") according to the impact analysis. This doesn't make sense, because if 
I'm setting up a server or appliance, it is not (in most of the cases) a 
"temporary" thing.
    
    #True, so in that case when you set up a server in the DC of someone else 
and need v6PI get your own block from the RIPE NCC ??
    But yes I understand there can be more complicated situations....
    
    
    
    Also, the use of dynamic, may be confusing vs "persistent" (as we used in 
RIPE-690), as it may confuse regarding the usage of DHCP or something else, etc.
    
    I think this must be allowed, even if static/persistent, because I may need 
a service company coming to my network with their own devices, for example, 
installing IP video-cameras for surveillance. It doesn't make sense that they 
can't use my addresses, because that increase the complexity of the 
infrastructure, etc., even may force to have different networks.
    
    Regards,
    Jordi
     
     
    
    -----Mensaje original-----
    De: address-policy-wg <[email protected]> en nombre de 
Jetten Raymond <[email protected]>
    Fecha: jueves, 17 de enero de 2019, 14:03
    Para: JORDI PALET MARTINEZ <[email protected]>
    CC: "[email protected]" <[email protected]>
    Asunto: Re: [address-policy-wg] suggestions from the list about IPv6 
sub-assignment clarification
    
        Hello All,
        
        I have a maybe very strange opinion on this, so i'll share it with you.
        
        I agree with Jordi that the current situation is confusing and could be 
clearer...
        
        IPv6 PI should be used as very originally was intended, and it should 
not be subnetted or subdelegations should be made of it to other instances than 
the obtainer at all.
        
        Before you turn on the grill, what should be changed or made allowed or 
understood as intention, compared to the very original intention of PI IPv6 is 
that the temporary use as in f.ex your guest wlan, (the enduser will not get 
these ip:s with him/her when leaving the building, it’s a WLAN infrastructure 
that can be used as a "client" in this case even temporary).
        
        In a DC, as long as the infra and servers are used or more precisely 
accessed by clients, they also do not get the ip:s assigned, but use them to 
access these platforms. In these cases the ip subnets belong to the provider, 
not to the customer. (VPN is a service right?)
        
        If a customer of a  DC needs an assigned block for whatever reason, 
they can obtain a normal v6 block , or if PI v6 is needed, its still available, 
apply for a PI v6 subnet from Ripe. (or even become a member).
        
        I hope this helps
        
        Rgds,
        
        Ray
        
        -----Original Message-----
        From: address-policy-wg <[email protected]> On Behalf 
Of JORDI PALET MARTINEZ via address-policy-wg
        Sent: 17. tammikuuta 2019 14:13
        To: address-policy-wg <[email protected]>
        Subject: [address-policy-wg] suggestions from the list about IPv6 
sub-assignment clarification
        
        Hi all,
        
        As you know, I've been working on different versions of a clarification 
to 2016-04 (https://www.ripe.net/participate/policies/proposals/2016-04).
        
        This proposal allows a single IP to be sub-assigned, and the author 
explained (not just in the policy proposal text, but also in the justification 
and in different emails), that the case they have is to make sure that the 
policy allows it for:
        1) Datacenter services.
        2) Interconnections (VPN, PNI, p2p, etc.).
        3) Guess visitors (employees, hotspot users, etc.).
        
        The policy text doesn't mention those examples, but the summary talks 
about them:
        "Intended use cases for IPv6 PI space in the spirit of this policy 
proposal are the use in (public) WIFI networks (like the WIFI at RIPE 
meetings), as transfer networks on PNIs or other PTP-links/VPNs to users or 
customers, or for housing/hosting for servers in data centres. The use of IPv6 
PI space for DSL/cable/FFTH/etc. subscribers is explicitly not an intended use 
case for this policy proposal."
        
        On the other side, the impact analysis indicates:
        "It is the RIPE NCCs understanding that assignments as described above 
are dynamic in nature, either by varying the prefix or interface identifier 
(IID) over time. Any permanent and static assignments of a prefix would still 
be considered a sub-assignment as per clause 2.6, “Assign” of the IPv6 address 
allocation and assignment policy. Consequently the RIPE NCC will not provide 
IPv6 PI assignments for such deployment plans."
        
        I don't think this is very clear, because
        1) DC addresses usually are static.
        2) Interconnections usually are static (p2p links at least).
        
        On the other side, as explained in my previous versions, I think that 
it is a valid case (in a hotspot, DC, etc.), instead of providing a single 
address, provide a full prefix (for example /64), so the host can have Virtual 
Machines running on different addresses of the same prefix.
        
        So, in my understanding we really need to clarify this text and for 
that, we need to decide what we want to be allowed and what not.
        
        So my questions are:
        1) Do we agree that only dynamic should be allowed, or static is also 
ok?
        2) According to 1 above, should the DataCenter case be alllowed?
        
        Thanks!
        
        Regards,
        Jordi
         
         
        
        
        
        **********************************************
        IPv4 is over
        Are you ready for the new Internet ?
        http://www.theipv6company.com
        The IPv6 Company
        
        This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.
        
        
        
        
        
        
    
    
    
    **********************************************
    IPv4 is over
    Are you ready for the new Internet ?
    http://www.theipv6company.com
    The IPv6 Company
    
    This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.
    
    
    
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.





Reply via email to