Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt

My take on this.

Most of the RIR policies allow a shorter prefix than /48 for a single site if justified. As Tim said, there are already examples of /44 and I’ve seen others (/47).

If you are using a single /64 per host, and furthermore an IETF RFC documents it, a RIR policy can’t block it. In the worst case, a RIR policy can always be modified by the community, and I think this can happen in general in less than 4-6 months in most of the regions, looking at most of the PDP process overall length.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <v6ops-bounces@ietf.org> en nombre de Tim Chown <Tim.Chown@jisc.ac.uk>
Responder a: <Tim.Chown@jisc.ac.uk>
Fecha: lunes, 7 de agosto de 2017, 12:05
Para: David Farmer <farmer@umn.edu>
CC: Simon Hobson <linux@thehobsons.co.uk>, v6ops list <v6ops@ietf.org>
Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt

    Hi,

    > On 7 Aug 2017, at 07:08, David Farmer <farmer@umn.edu> wrote:
    > 
    > On Sun, Aug 6, 2017 at 3:42 PM, Simon Hobson <linux@thehobsons.co.uk> wrote:
    > Sander Steffann <sander@steffann.nl> wrote:
    > 
    > > Most (all?) RIRs allow a /48 per site. I haven't seen ISPs give one /48 to a customer and then divide it over the connections ("sites") that that customer has. It far more convenient for everybody to just give each connection/site a separate /48. And business-ISP really shouldn't give any customer any less.
    > 
    > What about businesses with multiple sites (or even, just multiple buildings on a large site), connected by leased lines or whatever, and one central internet connection ? It's not that uncommon. Some time ago (different job) I managed a network with 45 sites and only one internet connection - 40 of them were retail outlets, using dial on demand ISDN, and the ONLY networking they had was back to head office for PoS systems. OK, not typical, but as I say, not all that rare either.
    > These days it would be mostly done with DSL lines and VPNs - but we'd still not be allowing local use of the internet connection at each store.
    > 
    > As I've been pointing out - there are comments along the lines of "we must not block future innovation". Yet at the same time there are limitation being hardcoded in that do exactly that. Just think about it, even if the entire /48 is used on one network, then that only gives 16 bits for host selection - with 60+ bits "wasted". While at the same time there are those saying that anything less than 64 bits to pick an address from is inadequate.
    > 
    > This discussion seem to be rapidly spinning out of the IETF's preview, but it is still important. I think the RIR assignment and allocation policies aren't as stingy as some might think.  Organizations with multiple sites should not be limited to only a /48, in fact /48 is really just the staring point, at least in the ARIN region /44s and /40s are not that difficult to justify for most organizations. 

    Two UK universities have a /44 due to their internal organisation.

    > ARIN's policy explicitly allows the assignment of a /48 for each site of a multi-site end-user, either by an ISP or directly by ARIN (if one of several qualifications is meet by the end-user), further additional /48s per site can be assigned if 16,384 /64 subnets are used in an single x-large site.  However, the policy is really a ceiling for ISPs, and ISPs are free to assign less if they see fit. Also, it could very well be the case that if an end-user has multiple sites behind a single connection to an ISP, the ISP might not realize the end-user has multiple site unless the end-user requests a block larger than /48. It seems quit logical for an ISP to assume a connection is just one site, unless the customer informs them otherwise.
    > 
    > ARIN's IPv6 end-user policy;
    > https://www.arin.net/policy/nrpm.html#six58
    > 
    > The follow allow ISPs or LIRs to make IPv6 assignment based on the above end-user policy;
    > https://www.arin.net/policy/nrpm.html#six54
    >  
    > On the other hand as I have been listening to this discussion, and I've become a little concerned that some may think this new model of a /64 per host should replace or obsolete the more traditional subnet model of multiple hosts within a subnet for any and all use cases. However, it should be noted that the primary use case for this model is public internet access, or public WiFi. There are several arguments that the traditional subnet model has always been a bad fit for this use case, in that you end up mixing totally unrelated users and hosts on the same subnet, there are several security and privacy issues with that. This isn't necessarily true of other use cases.
    > 
    > So, the /64 prefix per host model solves some important problems for this, and maybe other use cases too. But, that doesn't mean it should be viewed as a universal replacement for the traditional multiple host per subnet model for all use cases we have. There are plenty of use cases left where traditional multiple host per subnet model still works just fine.

    The question though, as and as you say it’s not one really in the IETF’s scope, more the RIR communities, is if a site has a /48, and uses it up (or 16,384 /64s of it up) implementing draft-ietf-v6ops-unique-ipv6-prefix-per-host, will that be deemed appropriate use to allow a further assignment?

    A large university may choose to implement this on its wifi/eduroam, for example.

    Tim
    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops

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

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.