[175111] in North American Network Operators' Group
Re: IPv6 Default Allocation - What size allocation are you giving out
daemon@ATHENA.MIT.EDU (Owen DeLong)
Thu Oct 9 10:27:52 2014
X-Original-To: nanog@nanog.org
From: Owen DeLong <owen@delong.com>
In-Reply-To: <54366AB9.3040504@gmail.com>
Date: Thu, 9 Oct 2014 10:19:16 -0400
To: Paige Thompson <paigeadele@gmail.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>, manning bill <bmanning@isi.edu>
Errors-To: nanog-bounces@nanog.org
Policy allows any ISP (LIR) with need greater than /32 to easily qualify for=
what they need up to /12. I know of at least two entities that have applied=
for and with minimal effort and appropriate justification, received /24 all=
ocations and many with /28s.=20
Owen
> On Oct 9, 2014, at 07:00, Paige Thompson <paigeadele@gmail.com> wrote:
>=20
> makes more sense to hand out /48s imho. theres only a mere 65k /48s per
> /32 (or something like that), though.
>=20
>=20
>> On 10/09/14 12:29, Mark Andrews wrote:
>> In message <1AA6F1A9-D63B-4066-903D-0E8690C7C567@isi.edu>, manning bill w=
rites:
>>> yes! by ALL means, hand out /48s. There is huge benefit to announcing =3D=
>>> all that dark space, esp. when
>>> virtually no one practices BCP-38, esp in IPv6 land.
>>>=20
>>>=20
>>> /bill
>>> PO Box 12317
>>> Marina del Rey, CA 90295
>>> 310.322.8102
>> and if everyone hands out /48's you just filter /48's. With a mix of /56=
>> and /48 you need to filter at the /56 level. Given enterpises are gettin=
g
>> /48's it will be simpler overall for everyone to get /48's.
>>=20
>>>> On 8October2014Wednesday, at 18:31, Mark Andrews <marka@isc.org> wrote:=
>>>>=20
>>>> =3D20
>>>> Give them a /48. This is IPv6 not IPv4. Take the IPv4 glasses off
>>>> and put on the IPv6 glasses. Stop constraining your customers
>>>> because you feel that it is a waste. It is not a waste!!!! It
>>>> will also reduce the number of exceptions you need to process and
>>>> make over all administration easier.
>>>> =3D20
>>>> As for only two subnets, I expect lots of equipment to request
>>>> prefixes in the future not just traditional routers. It will have
>>>> descrete internal components which communicate using IPv6 and those
>>>> components need to talk to each other and the world. In a IPv4
>>>> world they would be NAT'd. In a IPv6 world the router requests a
>>>> prefix.
>>>> =3D20
>>>> Mark
>>>> =3D20
>>>> In message <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads>, =3D=
>>> Erik Sun
>>>> dberg writes:
>>>>> I am planning out our IPv6 deployment right now and I am trying to =3D=
>>> figure o=3D3D
>>>>> ut our default allocation for customer LAN blocks. So what is =3D
>>> everyone givi=3D3D
>>>>> ng for a default LAN allocation for IPv6 Customers. I guess the idea =3D=
>>> of ha=3D3D
>>>>> nding a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me =3D=
>>> cring=3D3D
>>>>> e at the waste. Especially when you know 90% of customers will never =3D=
>>> have m=3D3D
>>>>> ore than 2 or 3 subnets. As I see it the customer can always ask for =3D=
>>> more I=3D3D
>>>>> Pv6 Space.
>>>>> =3D20
>>>>> /64
>>>>> /60
>>>>> /56
>>>>> /48
>>>>> =3D20
>>>>> Small Customer?
>>>>> Medium Customer?
>>>>> Large Customer?
>>>>> =3D20
>>>>> Thanks
>>>>> =3D20
>>>>> Erik
>>>>> =3D20
>>>>> ________________________________
>>>>> =3D20
>>>>> CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, =3D=
>>> files =3D3D
>>>>> or previous e-mail messages attached to it may contain confidential =3D=
>>> informa=3D3D
>>>>> tion that is legally privileged. If you are not the intended =3D
>>> recipient, or =3D3D
>>>>> a person responsible for delivering it to the intended recipient, you =3D=
>>> are h=3D3D
>>>>> ereby notified that any disclosure, copying, distribution or use of =3D=
>>> any of =3D3D
>>>>> the information contained in or attached to this transmission is =3D
>>> STRICTLY P=3D3D
>>>>> ROHIBITED. If you have received this transmission in error please =3D
>>> notify th=3D3D
>>>>> e sender immediately by replying to this e-mail. You must destroy the =3D=
>>> origi=3D3D
>>>>> nal transmission and its attachments without reading or saving in any =3D=
>>> manne=3D3D
>>>>> r. Thank you.
>>>> --=3D20
>>>> Mark Andrews, ISC
>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>>> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
