[arin-ppml] Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension - IAB comment

Alain Durand adurand at juniper.net
Wed Jun 29 16:20:36 EDT 2011



Sent from my iPhone

On Jun 29, 2011, at 3:35 PM, "Owen DeLong" <owen at delong.com> wrote:

> 
> On Jun 29, 2011, at 12:21 PM, Joel Jaeggli wrote:
> 
>> 
>> On Jun 29, 2011, at 12:05 PM, Owen DeLong wrote:
>> 
>>> 
>>> On Jun 29, 2011, at 7:02 AM, Alain Durand wrote:
>>> 
>>>> 
>>>> On Jun 29, 2011, at 9:53 AM, William Herrin wrote:
>>>> 
>>>>> 
>>>>> 2. Regardless of the disposition of 2011-5, the vendors and protocol
>>>>> authors who made assumptions about NAT based on the assigned IP
>>>>> address are about to get an object lesson in respecting the corner
>>>>> case.
>>>> 
>>>> 
>>>> This logic is hard coded just about everywhere. Check your Windows machine and see what it does based on which IP address it is configured with.
>>>> One could reverse your comment and say: ISP who do not take this fact into account take the risk of generating high volume of service call.
>>>> 
>>>> - Alain.
>>> 
>>> But the only place it will matter in these cases is the home gateways.
>> 
>> Actually it exists anywhere a home pc is directly connected to the cable modem, like my grandfathers house for example...
>> 
>> And, the logic exists in home gateways, that you can buy at frys, they say linksys on them, and and d-link and so forth.
>> 
> 
> Any place NAT444 gets implemented with non-1918 addresses (which I think is likely to be the vast majority of NAT444
> deployments), this assumption will break. Allocating this /10 won't change that fact, it will just reduce the total number
> of addresses allocated for that purpose _AND_ allow firmware updates to address that breakage if the CPE/OS vendors
> choose to do so.
> 
> Owen
> 


This is why going with RFC1918 is the safest choice. Dealing with inside/outside address range conflict is,  IMHO, much easier than dealing with the brokeness induced here.

Alain.


More information about the ARIN-PPML mailing list