[AusNOG] RFC7278 - "Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link"

Joseph Goldman joe at apcs.com.au
Wed Jul 2 22:28:47 EST 2014


I understand the vastness of the IPv6 address space, and to be fair, the 
same words were likely uttered a couple decades ago with IPv4, but in 
any case I was more just hoping to learn an answer beyond 'Just Because'.

A couple I've found while googling, and one of the responses on-list:

   1) (and probably most importantly) a lot of IPv6 features rely on a 
subnet size of /64 (SLAAC given as the example)
   2) Route summarisation i.e. if we had trillions of /96's or smaller 
to learn in a full table (and given an IPv6 route takes up something 
like 4x the space), these are quite large routing tables.

It's mind boggling to think, how many /64's I can essentially hand out 
with my single allocation of /32. If I'm not mistaken, there are as many 
/64's in a /32, as there is IPv4 address' available in total?!

On 02/07/14 22:21, Matthew Scutter wrote:
> http://www.wolframalpha.com/input/?i=2%5E64+%2F+population+of+earth
> We'll be fine for the foreseeable future, and probably a while beyond it.
>
>
> On Wed, Jul 2, 2014 at 9:31 PM, Joseph Goldman <joe at apcs.com.au 
> <mailto:joe at apcs.com.au>> wrote:
>
>     Hi Mark,
>
>      Going a bit off-topic, towards IPv6 in general as I'm still
>     catching up on the standards of use for IPv6, but I am yet to
>     understand the reason for recommendations to give such large
>     blocks to customers?
>
>      You talk about a /64 being handed out to customers, even this I
>     found exceptionally large for a home, which even with smart
>     devices becoming the norm would you say its likely to reach 100
>     needed IP's? let alone thousands?
>
>      You go on to say other RFC's are even trying to recommend /56's,
>     or even /48 to be better by your own personal opinion. Why so
>     large? Why not /96's or even smaller?
>
>      I'm in no way knocking the idea, I am genuinely curious as to the
>     reasons behind the recommendations.
>
>     Thanks in advance!
>     Joe
>
>
>     On 02/07/14 21:14, Mark ZZZ Smith wrote:
>
>         Hi,
>
>         The following recently published RFC might be of interest to
>         people on this list.
>
>         RFC7278 - "Extending an IPv6 /64 Prefix from a Third
>         Generation Partnership Project (3GPP) Mobile Interface to a
>         LAN Link"
>
>         http://tools.ietf.org/html/rfc7278
>
>         Earlier versions of the 3GPP standards (i.e., basically mobile
>         phone data standards) didn't recognise or realise that
>         smartphones would also be able to temporarily become IP
>         routers/Wifi hotspots, and therefore didn't specify DHCPv6-PD.
>         This RFC describes how to take a /64 from the phone to carrier
>         link and use it/share it with the phone's Wifi LAN interface
>         when the phone is acting as an IPv6 router. It may seem a bit
>         obscure, however it provides some examples of how IPv6's
>         capabilities can be used to novelly overcome this limitation.
>         It certainly isn't a recommendation to give a customer a
>         single /64 rather than many of them (i.e., as per RFC6177, a
>         /56, or better IMO, a /48 as per the considerations in
>         RFC3177), but it does show how that can be worked around with
>         some limitations.
>
>         Regards,
>         Mark.
>         _______________________________________________
>         AusNOG mailing list
>         AusNOG at lists.ausnog.net <mailto:AusNOG at lists.ausnog.net>
>         http://lists.ausnog.net/mailman/listinfo/ausnog
>
>
>     _______________________________________________
>     AusNOG mailing list
>     AusNOG at lists.ausnog.net <mailto:AusNOG at lists.ausnog.net>
>     http://lists.ausnog.net/mailman/listinfo/ausnog
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20140702/0807c61e/attachment-0001.html>


More information about the AusNOG mailing list