[ppml] Follow on to 2003-4, and suggested change.

[Owen DeLong]

In that case, I would argue that DSL providers would face the same need to hand
out /48s to their customers.  Afterall, I am a residential ADSL subscriber with
multiple subnets and several routers at the end of my DSL connections.  THere
are enough people like me (and there would be more if most ADSL providers
didn't have such desperate need for anal cranectomies) that I do not think
you can safely say that all residential DSL customers should get a /64.

I agree with Leo that if the customer topology indicates no layer 3 routing
devices, the customer should receive a /64.  If they later decide to add
some layer 3 devices, they can (and should) renumber into a /48.

Owen


--On Monday, October 27, 2003 04:33:53 PM +0000 Michael.Dillon at radianz.com wrote:

>> A large aspect of our business is running data centers.  Typically
>> we drop off a 100Mbps FE, or 1000Mbps GE link to a customer who
>> plugs in a number of layer 2 switches and installs many servers.
>
>> As far as I can tell the best thing to do with these customers is
>> assign a /64.  A shorter prefix would be a waste, as they own no
>> layer 3 gear, so they would have no way to break it into separate
>> lans anyway.  I suspect anyone who runs data centers will generally
>> be assigning /64's in the data centers to customers.
>
> I don't think this is consistent with IPv6 policy. Specifically, the
> policy says:
>
>     Assignments are to be made in accordance with the existing guidelines
>     [RFC3177,RIRs-on-48], which are summarized here as:
>
>     - /48 in the general case, except for very large subscribers
>
>     - /64 when it is known that one and only one subnet is needed by
> design
>
> I don't think you can say that one and only one subnet is needed by design
> because it is your
> customer's network and not yours. If a customer asks you for an IPv6
> assignment then you would
> have to ask the customer to agree to not *EVER* install a router or a
> firewall or a NAT
> device otherwise you don't have a design rule to justify the /64.
>
> The prudent thing to do here would be to assign a /48 because this is an
> endsite network
> outside of your management control. They may assign a separate subnet with
> separate addresses
> for managing their devices. They may set up a separate subnet with
> separate physical interfaces for
> doing backups of their servers. They may deploy a firewall that needs a
> DMZ subnet.
>
> There is no waste of addresses by doing this. Remember that IPv6 gives us
> 340 undecillion, 282 decillion, 366 nonillion, 920 octillion,
> 938 septillion, 463 sextillion, 463 quintillion, 374 quadrillion,
> 607 trillion, 431 billion, 768 million, 211 thousand, 456 addresses
> to use. That is an awful lot of room, unimaginably huge. The people
> who have thought these things through carefully, think that it's ok
> to use up an entire /48 for any network that might grow and change
> in topology. For now, we should accept that and work with it. Save the
> /64 allocations for cell-phones and PDAs were there is unlikely to be
> more than one subnet on the device. If there is any network infrastructure
> beyond your demarc, including a layer 2 switch, then you probably cannot
> predict whether or not they will someday need to subnet. Therefore, /48.
>
> --Michael Dillon
>
>



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031027/290187ce/attachment.sig>