[arin-ppml] ARIN-prop-127: Shared Transition Space for IPv4 Address Extension

Owen DeLong owen at delong.com
Mon Jan 24 04:19:43 EST 2011


On Jan 23, 2011, at 8:34 PM, Joel Jaeggli wrote:

> Consider whose foot is beeing shot when you take some previously globaly scoped ipv4 space give it a private scope and don't give the host stacks time to figure it out. 
> 
Um, nobody's... At least that's what happened with RFC-1918. It was in wide use well
before the RFC was finalized. To the best of my knowledge, nobody's host stack
treats RFC-1918 space any different from any other global unicast. As such, I'm not
sure what you're getting at here.

> I'm of the opinion that this was a bad idea at the IETF and it's a bad idea here to. I made a suggestion as to how a opertor consortia or even an individual entity could cough up the space necessary to make it work and I'm convinced that if the need for it were that dire we'd see a proposal altering the transfer rules such that a new entity could be created without penalty, rather asking for an assignment by fiat that ultimately is simply another private use prefix that happens to confuse nat traveral hacks until hosts catch up with it.
> 
I'm not sure why you think NAT traversal hacks care about which addresses are
private vs. public. If they do, then, they don't work in NAT cases where neither
side of the NAT is within RFC-1918 today, which is a perfectly valid use case.

Owen

> Owen DeLong <owen at delong.com> wrote:
> 
>> 
>> On Jan 23, 2011, at 1:10 PM, Mark Smith wrote:
>> 
>>> On Sun, 23 Jan 2011 12:01:39 -0600
>>> "Frank Bulk" <frnkblk at iname.com> wrote:
>>> 
>>>> So that operators in ARIN's region have a reasonable path to NAT444.  No one
>>>> likes NAT444 and we acknowledge that this designated space could be used for
>>>> purposes other than what the reasons that led to this policy proposal, even
>>>> if the policy proposal specified otherwise.  But as Owen said, the operator
>>>> would be shooting themselves in the foot.  By the time they use this space
>>>> for *something else* and then wanted to do NAT444, they would not be able to
>>>> justify a request for IPv4 space for NAT444.  
>>>> 
>>> 
>>> There's been plenty of foot shooting in the past with private and
>>> non-allocated address space. Why is this time going to be any
>>> different? Giving away more address space with RFC1918's properties
>>> will only provide a level of legitimacy to further foot shooting -
>> 
>> The question is who is doing the shooting and whose foot is being shot.
>> 
>> In this case, you've got a situation where the IETF and the end users
>> have managed to shoot the ability to deploy NAT444 in the foot.
>> 
>> If we set aside this /10, that restores the ability for the ISPs to deploy
>> NAT444 (bullet removal). Now, if an end-user proceeds to use this
>> space, then they have shot off their own foot and I doubt anyone will
>> have much sympathy for them. In other words, they can only harm
>> themselves, not their ISP, not the rest of the community, so, who cares?
>> 
>>> people will ignore what this space is specifically for because by its
>>> nature it can't be policed - I'm guessing the Hamachi people
>>> will start using it straight away since they "lost" 5/8. If this /10
>>> never exists, then whenever people try to shoot themselves in the foot
>>> they'll unavoidably know they're about to do it. Of course you can't
>>> prevent stupidity, but you can make it more obvious that it is
>>> occurring.
>>> 
>> This isn't about people who shot themselves in the foot. This is about
>> people who are loosing feet from shots fired by other people.
>> 
>> Owen
>> 
>>>> Frank
>>>> 
>>>> -----Original Message-----
>>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>>>> Behalf Of George Bonser
>>>> Sent: Saturday, January 22, 2011 11:19 PM
>>>> To: Owen DeLong
>>>> Cc: arin-ppml at arin.net
>>>> Subject: Re: [arin-ppml] ARIN-prop-127: Shared Transition Space for IPv4
>>>> Address Extension
>>>> 
>>>> <snip>
>>>> 
>>>> Why should the network come out of ARIN's hide?  If APNIC and
>>>> IETF won't support it, why should ARIN?
>>>> 
>>>> <snip>
>>>> 
>>>> _______________________________________________
>>>> 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.
>> 




More information about the ARIN-PPML mailing list