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

[Mark ZZZ Smith]

----- 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
>