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

Sun Jul 20 20:26:07 EST 2014

So much that you rolled it out at home today :P

Kindest Regards,
Nathan Brookfield

Chief Executive Officer
Simtronic Technologies Pty Ltd

Web: http://simtronic.com.au
Phone: 1300 592 330
Fax: (02) 4749 4950

On 3 Jul 2014, at 10:23, "Joseph Goldman" <joe at apcs.com.au<mailto:joe at apcs.com.au>> 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<mailto:joe at apcs.com.au>>
To: ausnog at lists.ausnog.net<mailto: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<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

_______________________________________________
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/20140720/8208258d/attachment.html>