On Sep 17, 2011, at 8:24 PM, Usman Latif wrote:

I sense the recommendations for /64 assignments even to residential users looks more political than technical.


I don't think very many people are advocating giving such a small assignment to residential users. The smallest common
practice I am aware of is /60s and most providers are doing at least /56. I still think /48 is better.

It seems that because end-hosts and other systems have already been built with more support for stateless autoconfig, this may act as a roadblock for us.


The protocol was designed with stateless autoconf in mind. I'm not sure why you insist on ignoring this fact.

First of all, the RFC-6177 does not give the reasoning behind suggesting /64 as being technically motivated but more from the perspective of growth and scalability - I for one am having a hard time imagining how a "residential site" can grow to such a length that it would need 2^64 address space.
I quote from 6177:


You need a bigger imagination.

It's really not about dense packing the hosts into the /64 and actually having 18 quintillion hosts on a subnet. Of course, nobody would do that, it exceeds the practical scaling limits of the layer 2 topology.

However, it means that you don't have to worry about counting hosts. Every network has enough numbers available for every host.

"At the same time, it might be tempting to give home sites a single /64, since that is already significantly more address space compared with today's IPv4 practice. However, this precludes the expectation that even home sites will grow to support multiple subnets going forward. Hence, it is strongly intended that even home sites be given multiple subnets worth of space, by default. Hence, this document still recommends giving home sites significantly more than a single /64, but does not recommend that every home site be given a /48 either."


Yes… In other words, a /64 is too small for a home according to 6177. Admittedly, 6177 backed way off from the /48 recommendation for residential users, but, I believe that was caving to pressure from the IPv4-think crowd and not based on any real engineering data.

As regards stateless auto-configuration, one might argue that we have alternatives like RFC-3315 (DHCPv6) are also available but this may make the stateless implementation completely redundant (?)


Stateless autoconfiguration and DHCPv6 are both valid address auto-assignment mechanisms in IPv6. Each has its strengths and weaknesses. Each has applications it is well suited for and applications it is not at all well suited to.

Owen


From: Owen DeLong <owen@delong.com>
To: Usman Latif <osmankh@yahoo.com>
Cc: "mtinka@globaltransit.net" <mtinka@globaltransit.net>; Skeeve Stevens <Skeeve@eintellego.net>; "sig-policy@lists.apnic.net" <sig-policy@lists.apnic.net>
Sent: Sunday, 18 September 2011 8:25 AM
Subject: Re: [sig-policy] Need to understand logic behind assigning /64 IPv6 addresses



Sent from my iPad

On Sep 17, 2011, at 14:42, Usman Latif <osmankh@yahoo.com> wrote:

Ditto Mark -

And I tend to disagree that if IPv6 did not have autoconfiguration feature, then IPv6 would have been devised with only 64 bits ?? It does not make sense coz then you are only increasing 32 bits more to the current size of the IP which IMO would not have been a significant increase in the IP size. IMO IPv6 was

It would have been a 4.2Billion x increase. You don't think that's significant? You and I have very different ideas of what constitutes a significant increase in size.

If you go back and review the records of the IETF from the time, you will find that the discussion centered largely around a 64 bit address space until the idea of stateless auto configuration was proposed and that it did, indeed, spur the idea to add another 64 bits to cover it.

devised with 128 bits and was meant to address infinitely large number of hosts so that we never run out of addresses - and autoconfiguration etc were features added to IPv6 protocol later to make addressing easy.
I see autoconfiguration as a feature only and nothing more than that.

The history in the IETF mailing lists differs from your statement here.

RFC 4291 does not pose any restriction or requirement on the IPv6 address assignment architecture that every subnet should or must be /64 or /48 etc and why it cannot be a /112 or something smaller.


Correct. You can do whatever you want with your network. There are other places where /64, /48, and /32 are recommended and, IMHO, /64 per subnet, /48 per end site and minimum /32 per ISP are good starting points and current best common practice.

You are welcome to do otherwise, just as you are welcome to put sugar into your gas tank. However, being stingy with IPv6 resources will degrade the overall capability of your network(s) and possibly the internet, just as putting sugar in your gas tank will degrade the performance of your car.

Owen


From: Mark Tinka <mtinka@globaltransit.net>
To: Owen DeLong <owen@delong.com>
Cc: Skeeve Stevens <Skeeve@eintellego.net>; sig-policy@lists.apnic.net
Sent: Sunday, 18 September 2011 4:02 AM
Subject: Re: [sig-policy] Need to understand logic behind assigning /64 IPv6 addresses

On Sunday, September 18, 2011 01:43:13 AM Owen DeLong wrote:

> Multiple prefix sizes, address fragmentation, etc.
> Admittedly, it's a small complication, but, it is a
> complication.

> Further, it violates the principle of least surprise as
> your organization scales and brings in new engineers.

A good v6 address assignment policy for one's infrastructure
is neither difficult to create nor maintain.

No issues here since we started running v6 over 6 years ago.
We know how v6 can make address management within an ISP's
network brain-dead to maintain, but it's not reason enough
to use /64's where we can comfortably use /112's and still
not overly complicate our lives.

> So did I. I was being a little tongue in cheek/snarky
> with just presenting the math on the number of
> addresses,...

I know what you were getting at, with multiple v6 addresses
on a single interface, e.t.c.

> but the reality is that there may be some
> cases where having multiple addresses for one end of a
> point to point or the other (or both) may prove useful.
> These are admittedly rare.

Agree, but having run multiple networks with v6 over the
last several years, we're yet to find with a reason that has
required us to have multiple addresses on point-to-point
links either between infrastructure, or between AS domains.
Some things really are that simple :-).

Obviously, I can't speak for anyone else's network, just
ours.

Mark.

*              sig-policy:  APNIC SIG on resource management policy          *
_______________________________________________
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy