[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