Addressing plan exercise for our IPv6 course

Mark Smith nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org
Fri Jul 23 03:26:14 UTC 2010


On Fri, 23 Jul 2010 00:33:45 +0100
Matthew Walster <matthew at walster.org> wrote:

> On 22 July 2010 14:11, Alex Band <alexb at ripe.net> wrote:
> > There are more options, but these two are the most convenient weighing all
> > the up and downsides. Does anyone disagree?
> 
> I never saw the point of assigning a /48 to a DSL customer. Surely the
> better idea would be to assign your bog standard residential DSL
> customer a /64 and assign them a /56 or /48 if they request it, routed
> to an IP of their choosing.
> 

I estimate that an addressing request will cost the ISP at least 15
minutes of time to process. When a minimum allocation of a /32 contains
16 777 216 /56s, do you really need to create that artificial
addressing cost, eventually passed onto the customer?

With more address space than we need, the value we get is addressing
convenience (just like we've had in Ethernet addressing since 1982).
There is no need to make IPv6 addressing artificially precious and as
costly as IPv4 addressing is.

There are a variety of scenarios where customers, including
residential, will benefit from having multiple subnets. They may wish
to separate the wired and wireless segments, to prevent multicast IPTV
from degrading wireless performance. They may wish to segregate the
children/family PC from the adult PC network or SOHO network, allowing
the subnet boundary to be an additional Internet access policy
enforcement point. They'll need separate subnets if they wish to use a
different link layer technology, such as LoWPAN. They may wish to setup
a separate subnet to act as a DMZ for Internet facing devices, such as
a local web server for sharing photos with relatives. Game consoles may
be put in a separate subnet to ensure file transfers don't interfere
with game traffic latency, using the subnet ID as a QoS classifier.


> For the rest of it, I largely agree, though.
> 
> M
> 




More information about the NANOG mailing list