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

Sun Jul 20 20:22:56 EST 2014

To come back to this topic, in a clear opinion kind of way am I better 
deploying a /56 or /48's per end user?

After the discussions here - I came to accept that IPv6 numbers are 
staggering and always will be...but...a /48 is 65,000+ /64's, vs a /56 
which is 256 /64's, /56 seems more reasonable but I'd hate to have to 
renumber later in the game after everyone is used to having /56. Should 
I move to /48 straight away or keep to /56?

On 03/07/14 10:23, Joseph Goldman wrote:
> Thanks to you for responding after I completely hijacked your thread :),
> and to others on list for contributing to the discussion, Good post from
> Karl Auer should get a mention too!
>
> I enjoyed reading it and it has revamped my motivation for IPv6 deployment!
>
> On 03/07/14 07:43, Mark ZZZ Smith wrote:
>>
>>
>>
>> ----- Original Message -----
>>> From: Joseph Goldman <joe at apcs.com.au>
>>> To: ausnog at lists.ausnog.net
>>> Cc:
>>> Sent: Wednesday, 2 July 2014 9:31 PM
>>> Subject: Re: [AusNOG] RFC7278 - "Extending an IPv6 /64 Prefix from a
>>> Third Generation Partnership Project (3GPP) Mobile Interface to a LAN
>>> Link"
>>>
>>> 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?
>> This question has come up often enough that an IETF Internet Draft is
>> being written on the topic (I found out about the rational from the
>> book "IPv6: The New Internet Protocol (2nd Edition)" by  Christian
>> Huitema. That being said, I'd already had experience with other
>> protocols that had "excessively large" subnets, such as IPX.)
>>
>> "Analysis of the 64-bit Boundary in IPv6 Addressing"
>> http://tools.ietf.org/html/draft-ietf-6man-why64-01
>>
>> Ever thought about why MAC addresses are so big? Their primary
>> function is to uniquely identify interfaces/hosts on a single link,
>> and when the decision was made, the number of hosts on an Ethernet
>> segment was limited to 1000. So a 10 bit rather than 48 bit address
>> would have done the job. So in hind sight, has it and how useful has
>> it been that they are in the order of 38 bits or 274 877 906 944 times
>> larger than they actually needed to be? Unlike IPv4 and IPv6
>> addresses, we don't even both trying to recycle them - we just through
>> them away when we through away the network card or device it is part of!
>>
>> Somebody did write up a paper on why they chose 48 bit addresses,
>> which also has some good discussion about addressing in general e.g.,
>> flat verses hierarchical address schemes. (I in particular like the
>> description of a route as being a 'hint' about the destination
>> existing - the destination might not exist when the packet actually
>> arrives, despite what the series of 'hints' have said along the path
>> the packet has taken.)
>>
>> "48-bit Absolute Internet and Ethernet Host Numbers"
>> http://ethernethistory.typepad.com/papers/HostNumbers.pdf
>>
>>
>>>    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?
>> Because constantly 'right sizing' address assignment costs time and
>> effort. This has been an unavoidable cost in IPv4, because the address
>> space wasn't big enough in the first place for what IPv4 has ended up
>> being used for. Vint Cerf himself has said they thought they were
>> building network for a research project - "We assumed that national
>> scale networks were
>> expensive so there would not be too many of them."
>>
>> http://mailman.nanog.org/pipermail/nanog/2010-April/020488.html
>>
>> IPv6 could be seen as the first Internet Protocol designed to properly
>> solve the world-wide Internet problem (technically CLNS would have
>> too, but it had some drawbacks the IETF weren't happy with - variable
>> length addressing probably being the major one, although it also had a
>> Not Invented Here problem.) IPv4 was never meant to be used to build
>> the Internet we have today, and has only been able to be used to do so
>> by a series of neat, and not so neat hacks - Classes, Subnets,
>> Variable Length Subnets/CIDR and then 1:Many NAT.
>>
>>
>>>    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
>>>
>
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog