[arin-ppml] ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers

[Ted Mittelstaedt]

On 5/2/2012 9:48 PM, Kevin Blumberg wrote:
> Jimmy,
>
> In practice your description of renumbering is completely valid. I
> have found that there are always edge cases that complicate the
> situation. I had to renumber a /23 a couple years back that was
> supporting 1000 domains for webhosting. I used a similar method you
> described below and that handled 85 percent of the customers. Then
> the edge cases started cropping up, domains that we were not
> authoritative on, and the customer had hard coded the A records for
> the old IP netblock. Customers that had hard coded the IP inside of
> scripts and firewalls. We spent countless hours contacting the
> customers to complete the work and every time we had to tip toe
> because we were inconveniencing them.
>
> I consider the initial decision to  renumber out of PA space and get
> your first PI space hard enough. It is a careful balance of having
> freedom and flexibility with the work to renumber. To require  an
> organization to do it over and over again as they grow is wrong.
>

It is a greater wrong to require everyone else to spend lots of
money upgrading their router ram to hold larger tables just to make
things easier for some people.  1000 domains may seem like a lot but 
that figure is nothing compared to what is on the Internet today.

The balance is and always has been between the amount of work that
an org has to do to connect, vs the amount of work the rest of us
have to do to allow them to connect.


Ted

> Thanks,
>
> Kevin Blumberg
>
>
>
>
>
>
>> -----Original Message----- From: arin-ppml-bounces at arin.net
>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jimmy Hess Sent:
>> Thursday, May 03, 2012 12:12 AM To: Jo Rhett Cc:
>> arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-prop-167 Removal
>> of Renumbering Requirement for Small Multihomers
>>
>> 'On 5/1/12, Jo Rhett<jrhett at netconsonance.com>  wrote:
>>> On May 1, 2012, at 9:52 AM, William Herrin wrote:
>>>> First there's DNS pinning. Because of DNS pinning, web browsers
>>>> won't follow your new IP address when the DNS TTL runs out. In
>>>> some cases,
>>
>> What?  Web servers are a snap to renumber; DNS pinning is not an
>> issue.     Recursive DNS servers are harder to renumber,  because
>> the IP addresses are often configured directly by hand  on end user
>> systems, which means that a  per-system cost must be incurred  if
>> this activity cannot be automated,  IT staff time must be consumed
>> to reconfigure DNS server settings on each network device,   costs
>> are incurred to the END user of the ISP,  and they may be  annoyed
>> that their ISP's  renumbering  requires that they expend  man hours
>> to update configurations of their equipment.
>>
>> Unfortunately, the DNS RFCs don't provide a method for a
>> recursive DNS server to tell the end user client system to
>> permanently reconfigure the IP address of the server queried to the
>> new one (without end user intervention).
>>
>>
>>
>> A standard method of renumbering is to  transition services. Web
>> servers get configured with both old and new IP addresses. The DNS
>> records are updated, and both new and old IP addresses are valid
>> until renumbering is completed.
>>
>> DNS pinning beyond a normal DNS TTL period would be an anomaly,
>> and is likely a unique issue to be addressed by the end user   (by
>> rebooting their equipment).
>>
>> But beyond a few days, its an imaginary problem. Note that the ARIN
>> /24 policy allows a 12 month transition period, which is plenty of
>> time to have DNS changes to a webserver hostname take effect.
>>
>> Browser windows don't get left open for 3 months.    Even if the
>> DNS pinning _DID_ happen to be broken in some version of a major
>> browser in use by users;    that can be addressed by the amount of
>> time  that the renumbering is performed over.
>>
>> It is not as if the /24 assignment policy requirement is that the
>> ISP complete their renumbering  within 30 days.
>>
>> -- -JH _______________________________________________ PPML You are
>> receiving this message because you are subscribed to the ARIN
>> Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or
>> manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml Please contact
>> info at arin.net if you experience any issues.
> _______________________________________________ PPML You are
> receiving this message because you are subscribed to the ARIN Public
> Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your
> mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml Please contact
> info at arin.net if you experience any issues.