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

[Mark Andrews]

In message <53B3ED9E.3050409 at apcs.com.au>, Joseph Goldman writes:
> 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.

When IPNG was being designed it almost used 64 bits of addressing.
This would have involved everyone having to continue hand out just
big enough addresses block and manage the local component of the
address.

To avoid this 128 bits (2 x 64) was choosen with /80 networks based
on using IEEE MAC 48 addresses for the local component so that there
was no need manage the local component of the addresses of machines.
They could be self numbering.  Then it was realised that IEEE MAC
64 address were used in places so for uniformity the boundary shifted
to /64 which also helped with /64 cpus.  IEEE MAC 48 have a well
known mapping in the IEEE MAC 64 space.  /48 was chosen for a site
as it was big enough for almost all sites (2^16 subnets of /64).

So /48 and /64 were choosen to make thing simple.  ISP's and others
keep trying to second guess these decisions.

/64 is also big enough to support crytographicly generated addresses
(CGA)

Mark

> 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 Proje
> ct (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 standar
> ds) 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 d
> escribes 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 s
> eem 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 t
> o give a customer a single /64 rather than many of them (i.e., as per RFC6177, a /5
> 6, 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
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org