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

[Matthew Scutter]

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> 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
>> http://lists.ausnog.net/mailman/listinfo/ausnog
>>
>
> _______________________________________________
> AusNOG mailing list
> 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/dfde9f51/attachment.html>