Eu sinto que isso geralmente foi respondido suficientemente (há 240 trilhões% de alocações de/48
, o que significa que todos os humanos na Terra podem receber 30,0000% de alocações de/48
e ainda não sairemos). Mas observarei que a RFC 6177 de 2011 alterou a recomendação para ISPs e RIRs de "fornecer aos sites dos clientes um mínimo de /48
"para" fornecer aos sites dos clientes algo menor que /64
, provavelmente um /56
, mas use o julgamento "
Para citar o RFC:
While the /48 recommendation does simplify address space management
for end sites, it has also been widely criticized as being wasteful.
Eu não concordaria com isso. Mais uma vez, existem 240 trilhões% de alocações/48
. A extinção humana nos levará a esgotar-se. /48
s oferece muito mais espaço de endereçamento do que a maioria dos sites precisa, mas não é realmente um desperdício. Continua:
At the same time, it might be
tempting to give home sites a single /64
, since that is already
significantly more address space compared with today's IPv4 practice.
However, this precludes the expectation that even home sites will
grow to support multiple subnets going forward. Hence, it is
strongly intended that even home sites be given multiple subnets
worth of space, by default. Hence, this document still recommends
giving home sites significantly more than a single /64
, but does not
recommend that every home site be given a /48
either.
....
A key principle for address management is that end sites always be
able to obtain a reasonable amount of address space for their
actual and planned usage, and over time ranges specified in years
rather than just months. In practice, that means at least one
/64, and in most cases significantly more. One particular
situation that must be avoided is having an end site feel
compelled to use IPv6-to-IPv6 Network Address Translation or other
burdensome address conservation techniques because it could not
get sufficient address space.
O RFC também recomenda apenas dividir alocações em nibbles pares, então /60
, /56
, /52
, /48
, etc. Um /60
fornece aos usuários finais até 16 sub-redes, o que é ok , mas muito menos do que as 192 sub-redes 192.168.0.0/16 endereçamento privado em IPv4 permite. Não é difícil imaginar um usuário doméstico que precise de mais de 16 sub-redes. A maioria não vai, mas não é difícil de imaginar.
- assigning a longer prefix to an end site, compared with the
existing prefixes the end site already has assigned to it, is
likely to increase operational costs and complexity for the end
site, with insufficient benefit to anyone.
Eu já vi que alguns ISPs estão finalmente planejando a implantação do IPv6 para usuários domésticos, mas eles estão apenas fornecendo /64
e não estão fornecendo prefixos estáticos. Isso significa que os usuários domésticos não podem executar mais de uma sub-rede no IPv6 e isso é preocupante. É bastante comum que as casas tenham uma sub-rede para a maioria dos dispositivos e uma sub-rede para o Wifi do hóspede. Eu encorajaria outra sub-rede para dispositivos IoT smarthome, já que essas coisas parecem ter tantos bugs de firmware que você dificilmente quer que eles consigam acessar a internet, mas certamente não os querem com acesso à sua LAN. Com apenas um / 64, um usuário doméstico teria que: escolher qual sub-rede é compatível com IPv6 e usar IPv4 + NAT para as outras sub-redes ou usar IPv6 - IPv6 NAT.
Eu sinto que um /128
é razoável para um único servidor em alguns casos e um /64
em outros. Mas um /64
nunca é razoável para um site e, embora o RFC6177 dê mais espaço para os ISPs, provavelmente teríamos ficado com o "sempre dar pelo menos um / 48 aos sites dos usuários finais" de 2001 RFC 3177 sem danos.