[arin-ppml] ARIN-2011-5: Shared Transition Space for IPv4 Address Extension - Last Call

[George, Wes E [NTK]]

-----Original Message-----
From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of William Herrin
Sent: Monday, May 02, 2011 7:14 PM
To: George, Wes E [NTK]
Cc: Scott Leibrand; arin-ppml at arin.net
Subject: Re: [arin-ppml] ARIN-2011-5: Shared Transition Space for IPv4 Address Extension - Last Call

On Mon, May 2, 2011 at 4:39 PM, George, Wes E [NTK] <Wesley.E.George at sprint.com> wrote:
> On Mon, Apr 25, 2011 at 8:46 AM, George, Wes E [NTK] <Wesley.E.George at sprint.com> wrote:
>> IPv4 addresses used behind a NAT (inside pool) cannot be used for 
>> justification of new resources nor counted towards utilization 
>> calculations for existing resources.
>> NRPM 4.10.x (Shared Transition Space) defines a specific non-unique 
>> block to  be shared among multiple networks for this purpose.

> I don't understand your example, specifically how a transfer would figure into the discussion. Please try to rephrase.

Sorry, I was being snarky.

Under your wording, once I have placed equipment behind a NAT, I can never move it out in front of a NAT because its existence
doesn't justify addresses. You could probably fix that particular problem by saying "addresses _intended to be_ used behind a NAT."
______________
[WEG] I'm not totally opposed to that wording change. I don't really think that it's necessary, because I highly doubt that someone
would go to the trouble of putting something behind a NAT and *then* decide that they need to go to the transfer market to get more
space to undo all of that work, but it's certainly a case that the AC should consider when they (hopefully) update the wording of
this policy to address my concern. 


But there are more problems. For example, addresses behind a bastion host firewall would still qualify even though that's basically
the same use as the NAT. That's fundamentally unfair, which violates a basic precept of any public policy process..

And what about folks who decide to consume public addresses inside their stateful non-translating firewalls even though they've
locked it down where the only thing that passes is outbound tcp? Is it fair that folks trying to conserve with NAT should pay an
additional policy-level penalty while wasters don't?
______________
[WEG] we're not discussing a policy setting aside a /10 for their use, and based on Owen's reply, I think the same would be true for
the bastion host firewall. You continue to bring up examples of things that would certainly be open for discussion if the ARIN
community decides to legislate network design in the name of IPv4 address conservation, but in this case, it's a red herring. Like I
said, I want this policy to cover enforcement/justification on the specific use case that the policy is using to justify setting
aside this space. Nothing more.

Wes George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6753 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110503/88563a45/attachment.p7s>