ARIN-PPML Archive

[arin-ppml] IPv4 Depletion as an ARIN policy concern

joel jaeggli — 2009-11-03T00:05:55Z

Tony Hain wrote:
> Scott Leibrand wrote:
>> So I take it you consider the existing ULA's "statistical uniqueness)
>> to
>> be sufficient? One thing I've heard a small amount of support for is
>> to
>> have RIRs register unique addresses that are intended to be used for
>> private addressing, and assign them out of a range dedicated for that
>> purpose. I'm not sure if that's necessary, myself, but I'm open to
>> arguments from anyone who thinks so.
>
>
> For many organizations the risks associated with 'statistical' are
> unacceptable, either based on bad experiences with IPv4 mergers, or based on
> interpretation of regulatory requirements to mitigate such risks.

it's no worse than what they do with ipv4 today, along many dimensions
it's better.

> The
> original ULA-C work was tabled due to lack of PI policy, so it looked like
> an end-run around the RIR policy framework. Now that PI policy is in place
> it is time to complete that part of the story. I have resurrected the effort
> with the draft
> http://www.ietf.org/internet-drafts/draft-hain-ipv6-ulac-01.txt .

I'm not sure that the existance of proof longer prefix assignments than
a /32 (we're happy with our /43 btw) obviates the principle objection to
ula-c namely that if there exists a lower barrier to entry on the
availability of ula-c space then there is for pi-space that the
temptation to shop for an upstream willing to route it is extremely high.

Private address space needs to be sufficiently toxic that no-one will
consider routing it... ula-l actually achieves that.

> Rather than focus on the process of managing that space, for the moment I
> just want to get the technical requirements clearly established. If ARIN (or
> any RIR) chooses not to participate in the allocation of this space, that is
> a separable policy discussion for another day. Until the ULA-C space is
> clearly allocated to IANA, that discussion can't reasonably happen.

using unique public addresses for my private application, confers the
salubrious benefit of being able to advertise and then black hole all
traffic bound for those prefixes externally which I find quite
attractive personally.

> Tony
>
> _______________________________________________
> 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.
>

[arin-ppml] IPv4 Depletion as an ARIN policy concern

joel jaeggli — 2009-11-02T22:12:13Z

Scott Leibrand wrote:
> So I take it you consider the existing ULA's "statistical uniqueness) to
> be sufficient? One thing I've heard a small amount of support for is to
> have RIRs register unique addresses that are intended to be used for
> private addressing, and assign them out of a range dedicated for that
> purpose. I'm not sure if that's necessary, myself, but I'm open to
> arguments from anyone who thinks so.

Private address space isn't unique in v4 or v6 if you follow the ula-l
guidelines you get statistically non-intersecting but your uniqueness
guarantee isn't present. just like it isn't in ipv4. if this where a
problem in ipv4 no one would use it... ula-c is dead.

joel

> -Scott
>
> Chris Engel wrote:
>> Scott,
>>
>> I really didn't mean to stir up the NAT hornets nest again. I was
>> speaking in more general terms that things which do not specificaly
>> NEED to be tied to IPv6 to make it function should not be. NAT was
>> simply an example of my own particular pet-peeve area of this....I'm
>> sure others here have thier own....some of which MAY actually involve
>> ARIN policy.
>>
>> About the only thing that could be done policy-wise in regards the
>> feasability of NAT in IPv6 is simply ensure that certain address space
>> is reserved for Private Networks and will NEVER be handed out to
>> anyone to be publicaly routed... just as the 10.x.x.x /8 and
>> 192.168.x.x /16 spaces are currently reseved under IPv4. However, that
>> seems to already be covered by rfc4193.... so I'm not sure there is a
>> specific issue here.....other then to realize that the speed of IPv6
>> adoption may not be as quick as many here would hope for.
>>
>>
>>
>> Christopher Engel
>>
>>
>> -----Original Message-----
>> From: Scott Leibrand [mailto:scottleibrand at gmail.com]
>> Sent: Monday, November 02, 2009 2:00 PM
>> To: Chris Engel
>> Cc: 'arin-ppml at arin.net'
>> Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern
>>
>>
>> Chris Engel wrote:
>>
>>> IPv6's best chance of adoption is to make the transition from IPv4 as
>>> seamless as possible for everyone involved. Which also largely means
>>> not necessitating a change of the methodologies and practices that
>>> people currently use with IPv4 more then is really required. It also
>>> means not tying other agenda's to IPv6's bandwagon.
>>>
>>> The one thing that I think pretty much everyone can agree is a
>>> positive with IPv6 is more address space available....at least I
>>> certainly don't think anyone would perceive that as a negative. The
>>> more things that you require people surrender in order to achieve that
>>> additional address space (in my case it would be primarily NAT... but
>>> it could be anything else for some-one else).... the less likely it is
>>> they are to determine the positives outweigh the negatives of
>>> adoption.
>>>
>>> If an argument is worthy of making (such as the idea that NAT is bad
>>> and need be eliminated).... let that crusade be fought SEPARATELY from
>>> IPv6. The same holds true for things ARIN is directly responsible
>>> for...such as rules for the justification of IP address space.
>>>
>>> IPv6 may ALLOW for those issues to be addressed (such as some make the
>>> case it allows for the obsolescence of NAT or far more liberal
>>> requirements for receiving address space)..... however it should not
>>> NECESSITATE that they be....unless IPv6 itself cannot be made to
>>> function without them..... and if it does, then it's design is poorly
>>> conceived.
>>>
>>>
>>
>> Well put. In light of that, where do you see the need for policy
>> work? Are there places where ARIN policy is interfering with
>> transition by unnecessarily bundling other considerations into
>> addressing policy? Are there areas (such as the rules for
>> justification of IP address space) where we haven't yet done enough to
>> make the transition as painless as possible for everyone involved?
>>
>> Thanks,
>> Scott
>>
> _______________________________________________
> 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.
>

[arin-ppml] IPv4 Depletion as an ARIN policy concern

William Herrin — 2009-11-02T21:15:08Z

On Mon, Nov 2, 2009 at 7:33 PM, Owen DeLong wrote:
> On Nov 2, 2009, at 3:41 PM, William Herrin wrote:
>> On Mon, Nov 2, 2009 at 12:54 PM, Kevin Kargel
>> wrote:
>>> NAT started out as a kludgy local workaround and will always pretty much
>>> be
>>> a local workaround.
>>
>> NAT started out as an improvement on SOCKS that allowed most
>> applications to work unmodified. Understand why folks wanted the
>> latter and you'll understand why they want the former.
>>
> I don't buy this...

Owen,

IIRC, SOCKS came out in '92, TIS came along in '94 with a DARPA-funded
set of ALG's which were better. Then they improved those ALGs into
something they called "transparent proxyies" in their expensive
commercial firewall. That was the first thing that looked like what we
today call a NAT and what Cisco still insists on calling PAT.

Non-overloaded NAT came from a different direction, I'm not sure
where. I'm almost willing to buy the notion that stateful firewalls
with decent dynamic address management provides comparable capability
to non-overloaded NAT.

Regards,
Bill Herrin

--
William D. Herrin ................ herrin at dirtside.com bill at herrin.us
3005 Crane Dr. ...................... Web:
Falls Church, VA 22042-3004

[arin-ppml] IPv4 Depletion as an ARIN policy concern

Ted Mittelstaedt — 2009-11-02T20:16:38Z

Owen DeLong wrote:
>
> On Nov 2, 2009, at 3:41 PM, William Herrin wrote:
>
>> On Mon, Nov 2, 2009 at 12:54 PM, Kevin Kargel
>> wrote:
>>> NAT started out as a kludgy local workaround and will always pretty
>>> much be
>>> a local workaround.
>>
>> NAT started out as an improvement on SOCKS that allowed most
>> applications to work unmodified. Understand why folks wanted the
>> latter and you'll understand why they want the former.
>>
> I don't buy this...
>

Neither do I.

> SI started out as an improvement on SOCKS that allowed most
> applications to work unmodified. I can understand why folks wanted
> this, having run some SOCKS gateways and having worked with
> the guys at NEC that originally developed SOCKS.
>
> NAT was a kludge added to SI which allowed you to pack more
> addresses behind fewer addresses (or one address) by, essentially
> doing a statistical multiplexing of IP address+protocol+port number
> into a single 49 bit field which was dynamically assigned by the
> gateway.
>
> NAT restored the need to do application-specific weirdness to many
> applications which did not need such modifications for SI.
>
> If you look at it from this perspective, considering all the dysfunction
> created by overloading end system identifier semantics with network
> locator semantics (an error which was, unfortunately, preserved in
> IPv6), then, you can begin to see why further overloading is not
> necessarily a good thing.
>

As I recall - having setup my then-employer behind a roll-your-own
NAT on FreeBSD (using the kernel patches available then) back in 1997,
the biggest advantage of NAT at the time was because so much stuff was
statically assigned in the corporate network. It wasn't so much the
typing of the IP addresses into the clients. It was because so many
APPLICATIONS used statics.

I STILL to this day see this - as an example, take the Rosetta
foreign language learning software. To this very day when you setup
a Rosetta client in a network with a floating license server, the client
configuration software demands you key in the IP address of the license
server during the setup of the client. (on the OSX clients at least)
They use flexlm for that, by the way.

The problem as I see it is that a tremendously significant number of
corporate software application developers don't know squat about
networking. They may know how to write a network application but their
knowledge of it's interface to the network is restricted to the OS APIs
and they often will take shortcuts - such as not allowing for a user to
fill in a name, then doing a DNS query for it - if they think they can
get away with them.

I fully expect that some of these boneheads will be expecting the users
to key in the entire 128 bit address when they are finally forced to
write in IPv6 compatibility.

NATs allowed me to statically assign an IP number to a server then I
knew that years later I wouldn't have to renumber it and find all of the
clients that had it hard-coded, just because I decided to switch ISPs

Otherwise, NATs in a corporate environment are a royal PIA. Most
everyone uses 192.168.1.x or 192.168.0.x because that's the default
address on their router, and then when you try to setup a VPN from
company to company (which happens a lot more than you think) you have
trouble. I had a customer of the ISP call me the other day and complain
about this - she was a consultant who worked out of her home and she was
trying to VPN into 3 different clients of hers at once - all 3 running
192.168.1.x She tends to duplicate templates and such across clients
and now she has to disconnect from one and connect to another then
disconnect from that one and connect to the first again just to copy
over a template file. Really stupid, drives up her time, drives up
their bills.

Ted

[arin-ppml] IPv4 Depletion as an ARIN policy concern

Owen DeLong — 2009-11-02T19:33:13Z

On Nov 2, 2009, at 3:41 PM, William Herrin wrote:

> On Mon, Nov 2, 2009 at 12:54 PM, Kevin Kargel
> wrote:
>> NAT started out as a kludgy local workaround and will always pretty
>> much be
>> a local workaround.
>
> NAT started out as an improvement on SOCKS that allowed most
> applications to work unmodified. Understand why folks wanted the
> latter and you'll understand why they want the former.
>
I don't buy this...

SI started out as an improvement on SOCKS that allowed most
applications to work unmodified. I can understand why folks wanted
this, having run some SOCKS gateways and having worked with
the guys at NEC that originally developed SOCKS.

NAT was a kludge added to SI which allowed you to pack more
addresses behind fewer addresses (or one address) by, essentially
doing a statistical multiplexing of IP address+protocol+port number
into a single 49 bit field which was dynamically assigned by the
gateway.

NAT restored the need to do application-specific weirdness to many
applications which did not need such modifications for SI.

If you look at it from this perspective, considering all the dysfunction
created by overloading end system identifier semantics with network
locator semantics (an error which was, unfortunately, preserved in
IPv6), then, you can begin to see why further overloading is not
necessarily a good thing.

Owen

[arin-ppml] IPv4 Depletion as an ARIN policy concern

Tony Hain — 2009-11-02T19:17:34Z

Scott Leibrand wrote:
> So I take it you consider the existing ULA's "statistical uniqueness)
> to
> be sufficient? One thing I've heard a small amount of support for is
> to
> have RIRs register unique addresses that are intended to be used for
> private addressing, and assign them out of a range dedicated for that
> purpose. I'm not sure if that's necessary, myself, but I'm open to
> arguments from anyone who thinks so.

For many organizations the risks associated with 'statistical' are
unacceptable, either based on bad experiences with IPv4 mergers, or based on
interpretation of regulatory requirements to mitigate such risks. The
original ULA-C work was tabled due to lack of PI policy, so it looked like
an end-run around the RIR policy framework. Now that PI policy is in place
it is time to complete that part of the story. I have resurrected the effort
with the draft
http://www.ietf.org/internet-drafts/draft-hain-ipv6-ulac-01.txt .

Rather than focus on the process of managing that space, for the moment I
just want to get the technical requirements clearly established. If ARIN (or
any RIR) chooses not to participate in the allocation of this space, that is
a separable policy discussion for another day. Until the ULA-C space is
clearly allocated to IANA, that discussion can't reasonably happen.

Tony

[arin-ppml] IPv4 Depletion as an ARIN policy concern

William Herrin — 2009-11-02T18:41:34Z

On Mon, Nov 2, 2009 at 12:54 PM, Kevin Kargel wrote:
> NAT started out as a kludgy local workaround and will always pretty much be
> a local workaround.

NAT started out as an improvement on SOCKS that allowed most
applications to work unmodified. Understand why folks wanted the
latter and you'll understand why they want the former.

Regards,
Bill Herrin

--
William D. Herrin ................ herrin at dirtside.com bill at herrin.us
3005 Crane Dr. ...................... Web:
Falls Church, VA 22042-3004

[arin-ppml] ARIN-PPML Digest, Vol 53, Issue 5

Owen DeLong — 2009-11-02T17:15:22Z

On Nov 2, 2009, at 1:54 PM, Roger Marquis wrote:

> he.net's Owen DeLong wrote:
>> ... in IPv4, NAT is a necessary evil which is tolerated because
>> of the serious shortage of IPv4 addresses.
>
> That is the one of the opinions not supported by the facts. You may
> not
> have been around before NAT Owen, but those of us who were had no
> problem
> getting address space. We still assigned illegal addresses because
> there
> was no business case for allowing internal networks to be publically
> routable.
>
I was around before NAT. I was around well before NAT and I remember
when NAT first hit the streets. I remember the networks with bogon
addresses and the nightmares they caused when they suddenly found
themselves trying to integrate with real networks that played by the
rules. I don't expect it to be any different going forward with ULA or
any of the other private address and/or NAT proposals out there.

That doesn't make it any better of an idea now than it was then.

> But I do understand where you are coming from, a large ISP who will
> monitize its IPv4 address space in the event of an IPv4 shortage.
>
Uh, Say what?

1. While I work for an organization that may be considered a large
ISP, I can tell you that as an organization, we think that the
address market is a bad idea.

2. I was the ONLY vote on the ARIN AC in opposition to the
transfer market policy. How, exactly, does that put me in
the perspective of monetizing my IPv4 space?

3. NAT would actually make it easier for us to monetize our
address space if that's what we wanted to do.

>> However, in IPv6, that shortage is not present and therefore,
>> NAT moves from being a necessary evil to an UNnecessary evil.
>
> Amazing how network engineers can insist that real world managers,
> with
> real world issues, do not have a valid need for NAT. I wonder if he.net
> 's
> Board of Directors concurs?

I have no idea what HE.NET's board of directors thinks on the subject of
NAT. I haven't asked them. I am not speaking here for HE.NET, and,
the opinions expressed are the result of my 20+ years experience doing
networking ranging from small enterprise to major corporation and from
tiny ISP to major backbone provider.

There are lots of valid needs for private addressing or non-routed
addresses.
There are lots of valid needs for filtration and stateful inspection
firewalls.
There are even valid needs for the ability to support VIP-like
functionality.

Not one of those things actually requires NAT.

Owen
Just my opinion, not necessarily agreed with by anyone.

[arin-ppml] ARIN-PPML Digest, Vol 53, Issue 5

Roger Marquis — 2009-11-02T16:54:27Z

he.net's Owen DeLong wrote:
> ... in IPv4, NAT is a necessary evil which is tolerated because
> of the serious shortage of IPv4 addresses.

That is the one of the opinions not supported by the facts. You may not
have been around before NAT Owen, but those of us who were had no problem
getting address space. We still assigned illegal addresses because there
was no business case for allowing internal networks to be publically
routable.

But I do understand where you are coming from, a large ISP who will
monitize its IPv4 address space in the event of an IPv4 shortage.

> However, in IPv6, that shortage is not present and therefore,
> NAT moves from being a necessary evil to an UNnecessary evil.

Amazing how network engineers can insist that real world managers, with
real world issues, do not have a valid need for NAT. I wonder if he.net's
Board of Directors concurs?

Roger Marquis

[arin-ppml] IPv4 Depletion as an ARIN policy concern

Chris Engel — 2009-11-02T16:37:43Z

>From what I understand the space covered by rfc4193 should be fine for the use in private networks.....assuming that ISP's don't try to consider themselves as "private networks" and use that space as routable within the bounds of their own subscriber networks.....and then stick some sort of services on there which their subscribers might need (like access to account status, etc).

On the other hand what would be the consequences of the RIR's registering a unique address space in addition to that which could be utilized for private addressing? I assume it would reduce the size of the assignable IPv6 address pool.... but by how much actually?

Given the size of the IPv6 address pool... would doing so have that significant an effect on it? Not that I know of any current justification for it now. However, I'm one of those people who would rather hold something back upfront (if the impact isn't significant) and risk that there may not be a use for it down the line...then not hold it back and discover later on that there was a good use that wasn't contemplated.

Christopher Engel

-----Original Message-----
From: Scott Leibrand [mailto:scottleibrand at gmail.com]
Sent: Monday, November 02, 2009 3:28 PM
To: Chris Engel
Cc: 'arin-ppml at arin.net'
Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern

So I take it you consider the existing ULA's "statistical uniqueness) to be sufficient? One thing I've heard a small amount of support for is to have RIRs register unique addresses that are intended to be used for private addressing, and assign them out of a range dedicated for that purpose. I'm not sure if that's necessary, myself, but I'm open to arguments from anyone who thinks so.

-Scott

Chris Engel wrote:
> Scott,
>
> I really didn't mean to stir up the NAT hornets nest again. I was
> speaking in more general terms that things which do not specificaly
> NEED to be tied to IPv6 to make it function should not be. NAT was
> simply an example of my own particular pet-peeve area of this....I'm
> sure others here have thier own....some of which MAY actually involve
> ARIN policy.
>
> About the only thing that could be done policy-wise in regards the
> feasability of NAT in IPv6 is simply ensure that certain address space
> is reserved for Private Networks and will NEVER be handed out to
> anyone to be publicaly routed... just as the 10.x.x.x /8 and
> 192.168.x.x /16 spaces are currently reseved under IPv4. However, that
> seems to already be covered by rfc4193.... so I'm not sure there is a
> specific issue here.....other then to realize that the speed of IPv6
> adoption may not be as quick as many here would hope for.
>
>
>
> Christopher Engel
>
>
> -----Original Message-----
> From: Scott Leibrand [mailto:scottleibrand at gmail.com]
> Sent: Monday, November 02, 2009 2:00 PM
> To: Chris Engel
> Cc: 'arin-ppml at arin.net'
> Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern
>
>
> Chris Engel wrote:
>
>> IPv6's best chance of adoption is to make the transition from IPv4 as
>> seamless as possible for everyone involved. Which also largely means
>> not necessitating a change of the methodologies and practices that
>> people currently use with IPv4 more then is really required. It also
>> means not tying other agenda's to IPv6's bandwagon.
>>
>> The one thing that I think pretty much everyone can agree is a
>> positive with IPv6 is more address space available....at least I
>> certainly don't think anyone would perceive that as a negative. The
>> more things that you require people surrender in order to achieve
>> that additional address space (in my case it would be primarily
>> NAT... but it could be anything else for some-one else).... the less
>> likely it is they are to determine the positives outweigh the
>> negatives of adoption.
>>
>> If an argument is worthy of making (such as the idea that NAT is bad
>> and need be eliminated).... let that crusade be fought SEPARATELY
>> from IPv6. The same holds true for things ARIN is directly
>> responsible for...such as rules for the justification of IP address
>> space.
>>
>> IPv6 may ALLOW for those issues to be addressed (such as some make
>> the case it allows for the obsolescence of NAT or far more liberal
>> requirements for receiving address space)..... however it should not
>> NECESSITATE that they be....unless IPv6 itself cannot be made to
>> function without them..... and if it does, then it's design is poorly
>> conceived.
>>
>>
>
> Well put. In light of that, where do you see the need for policy
> work? Are there places where ARIN policy is interfering with
> transition by unnecessarily bundling other considerations into
> addressing policy? Are there areas (such as the rules for
> justification of IP address space) where we haven't yet done enough to
> make the transition as painless as possible for everyone involved?
>
> Thanks,
> Scott
>

[arin-ppml] IPv4 Depletion as an ARIN policy concern

William Herrin — 2009-11-02T16:07:43Z

On Mon, Nov 2, 2009 at 3:55 PM, Scott Leibrand wrote:
> In any event, do you see any particular areas where we could potentially
> improve address policy in light of the issues raised in this thread?

Scott,

Not especially, no. I don't see any solutions to these issues within
the scope of address policy.

I do see unrelated avenues for improvement in policy. Expect a draft.

Regards,
Bill Herrin

--
William D. Herrin ................ herrin at dirtside.com bill at herrin.us
3005 Crane Dr. ...................... Web:
Falls Church, VA 22042-3004

[arin-ppml] IPv4 Depletion as an ARIN policy concern

joel jaeggli — 2009-11-02T15:29:44Z

ULA-L is a v6 /8. that seems like enough private address space for most local network numbering needs...

Chris Engel wrote:

>Scott,
>
>I really didn't mean to stir up the NAT hornets nest again. I was speaking in more general terms that things which do not specificaly NEED to be tied to IPv6 to make it function should not be. NAT was simply an example of my own particular pet-peeve area of this....I'm sure others here have thier own....some of which MAY actually involve ARIN policy.
>
>About the only thing that could be done policy-wise in regards the feasability of NAT in IPv6 is simply ensure that certain address space is reserved for Private Networks and will NEVER be handed out to anyone to be publicaly routed... just as the 10.x.x.x /8 and 192.168.x.x /16 spaces are currently reseved under IPv4. However, that seems to already be covered by rfc4193.... so I'm not sure there is a specific issue here.....other then to realize that the speed of IPv6 adoption may not be as quick as many here would hope for.
>
>
>
>Christopher Engel
>
>
>-----Original Message-----
>From: Scott Leibrand [mailto:scottleibrand at gmail.com]
>Sent: Monday, November 02, 2009 2:00 PM
>To: Chris Engel
>Cc: 'arin-ppml at arin.net'
>Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern
>
>
>Chris Engel wrote:
>> IPv6's best chance of adoption is to make the transition from IPv4 as
>> seamless as possible for everyone involved. Which also largely means
>> not necessitating a change of the methodologies and practices that
>> people currently use with IPv4 more then is really required. It also
>> means not tying other agenda's to IPv6's bandwagon.
>>
>> The one thing that I think pretty much everyone can agree is a
>> positive with IPv6 is more address space available....at least I
>> certainly don't think anyone would perceive that as a negative. The
>> more things that you require people surrender in order to achieve that
>> additional address space (in my case it would be primarily NAT... but
>> it could be anything else for some-one else).... the less likely it is
>> they are to determine the positives outweigh the negatives of
>> adoption.
>>
>> If an argument is worthy of making (such as the idea that NAT is bad
>> and need be eliminated).... let that crusade be fought SEPARATELY from
>> IPv6. The same holds true for things ARIN is directly responsible
>> for...such as rules for the justification of IP address space.
>>
>> IPv6 may ALLOW for those issues to be addressed (such as some make the
>> case it allows for the obsolescence of NAT or far more liberal
>> requirements for receiving address space)..... however it should not
>> NECESSITATE that they be....unless IPv6 itself cannot be made to
>> function without them..... and if it does, then it's design is poorly
>> conceived.
>>
>
>Well put. In light of that, where do you see the need for policy work? Are there places where ARIN policy is interfering with transition by unnecessarily bundling other considerations into addressing policy? Are there areas (such as the rules for justification of IP address space) where we haven't yet done enough to make the transition as painless as possible for everyone involved?
>
>Thanks,
>Scott
>_______________________________________________
>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.
>

[arin-ppml] IPv4 Depletion as an ARIN policy concern

Scott Leibrand — 2009-11-02T15:27:54Z

So I take it you consider the existing ULA's "statistical uniqueness) to
be sufficient? One thing I've heard a small amount of support for is to
have RIRs register unique addresses that are intended to be used for
private addressing, and assign them out of a range dedicated for that
purpose. I'm not sure if that's necessary, myself, but I'm open to
arguments from anyone who thinks so.

-Scott

Chris Engel wrote:
> Scott,
>
> I really didn't mean to stir up the NAT hornets nest again. I was speaking in more general terms that things which do not specificaly NEED to be tied to IPv6 to make it function should not be. NAT was simply an example of my own particular pet-peeve area of this....I'm sure others here have thier own....some of which MAY actually involve ARIN policy.
>
> About the only thing that could be done policy-wise in regards the feasability of NAT in IPv6 is simply ensure that certain address space is reserved for Private Networks and will NEVER be handed out to anyone to be publicaly routed... just as the 10.x.x.x /8 and 192.168.x.x /16 spaces are currently reseved under IPv4. However, that seems to already be covered by rfc4193.... so I'm not sure there is a specific issue here.....other then to realize that the speed of IPv6 adoption may not be as quick as many here would hope for.
>
>
>
> Christopher Engel
>
>
> -----Original Message-----
> From: Scott Leibrand [mailto:scottleibrand at gmail.com]
> Sent: Monday, November 02, 2009 2:00 PM
> To: Chris Engel
> Cc: 'arin-ppml at arin.net'
> Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern
>
>
> Chris Engel wrote:
>
>> IPv6's best chance of adoption is to make the transition from IPv4 as
>> seamless as possible for everyone involved. Which also largely means
>> not necessitating a change of the methodologies and practices that
>> people currently use with IPv4 more then is really required. It also
>> means not tying other agenda's to IPv6's bandwagon.
>>
>> The one thing that I think pretty much everyone can agree is a
>> positive with IPv6 is more address space available....at least I
>> certainly don't think anyone would perceive that as a negative. The
>> more things that you require people surrender in order to achieve that
>> additional address space (in my case it would be primarily NAT... but
>> it could be anything else for some-one else).... the less likely it is
>> they are to determine the positives outweigh the negatives of
>> adoption.
>>
>> If an argument is worthy of making (such as the idea that NAT is bad
>> and need be eliminated).... let that crusade be fought SEPARATELY from
>> IPv6. The same holds true for things ARIN is directly responsible
>> for...such as rules for the justification of IP address space.
>>
>> IPv6 may ALLOW for those issues to be addressed (such as some make the
>> case it allows for the obsolescence of NAT or far more liberal
>> requirements for receiving address space)..... however it should not
>> NECESSITATE that they be....unless IPv6 itself cannot be made to
>> function without them..... and if it does, then it's design is poorly
>> conceived.
>>
>>
>
> Well put. In light of that, where do you see the need for policy work? Are there places where ARIN policy is interfering with transition by unnecessarily bundling other considerations into addressing policy? Are there areas (such as the rules for justification of IP address space) where we haven't yet done enough to make the transition as painless as possible for everyone involved?
>
> Thanks,
> Scott
>

[arin-ppml] IPv4 Depletion as an ARIN policy concern

Roger Marquis — 2009-11-02T15:17:51Z

Kevin Kargel wrote:
>> To state this another way, those of us who manage end-nodes will not be
>> purchasing IPv6 network gear that fails to support a standardized version
>> of NAT. Manufacturers will in turn not offer such equipment knowing it
>> will not sell. How anyone can continue to argue that IPv6 does not
>> require
> I am by no means arguing that IPv6 does not require NAT

Didn't mean to imply that you were, just that the implementation will need
to be standardized in order to avoid interoperability issues, and that lack
of interoperability is one of the two primary issues preventing IPv6 adoption.

Didn't mean to imply that you were, just that the implementation will need
to be standardized in order to avoid interoperability issues, and that
lack or interoperability is preventing IPv6 adoption.

>> NAT in light of this is beyond me, but I do hope you work for a
>> competitor.
> Wow, a little sensitive are we? It seems I struck a glancing blow to a
> nerve here. I hope you read again, I was not arguing that NAT is not
> needed, just that it is beside the point. Why argue about something that is
> going to happen no matter what we say?

Apologies Kevin. What I should have said is that I hope those who oppose
NAT in IPv6 (on an abstract technical basis, see Lee Dilkie's post of 10/28
for a good example) are employed at competitors.

Roger Marquis

[arin-ppml] IPv4 Depletion as an ARIN policy concern

Owen DeLong — 2009-11-02T15:15:01Z

On Nov 2, 2009, at 9:58 AM, Roger Marquis wrote:

> Kevin Kargel wrote:
>> NAT started out as a kludgy local workaround and will always pretty
>> much be
>> a local workaround. NAT is nothing more than a silly router trick.
>
> Whether or not NAT is "kludgy", a "workaround", or "silly" is an
> opinion.
> It is an opinion not supported by fact i.e., the market for end-node
> network gear without NAT, which is effectively zero. As a result
> arguments
> against NAT are irrelevant.
>
True... More accurately, in IPv4, NAT is a necessary evil which is
tolerated
because of the serious shortage of IPv4 addresses.

However, in IPv6, that shortage is not present and therefore, NAT
moves from
being a necessary evil to an UNnecessary evil.

Owen