Subject: Re: [OPSAWG] [v6ops] Heads up

From: Joel Jaeggli <[email-masked]>
Date: Tue, 09 Nov 2010 12:07:14 +0800

On 11/9/10 12:01 PM, Randy Bush wrote:
>> Chris Liljenstolpe has a proposal that he made in ops-area today, for
>> a mechanism to create what amounts to an RFC 1918 prefix, but
>> specifically for use in NAT444 ISP configurations. It involves a
>> request to the ARIN board. He will write a quick draft and post it
>> this week, discuss this Thursday in the Ops WG, and call the question
>> in Friday's v6ops meeting. Due to the real time nature of the
>> discussion, I'll ask folks to be aware and follow it.
> 
> i have been fighting against this wrong-headed proposal for a couple of
> years, since they first tried it in apnic, from which we sent them to
> ietf.
> 
> it is a hack which perpetuates their kludge and does not help ipv6 one
> little bit.  
> 
> they made the current mess and this just delays the inevitable and
> they'll want some other silliness to bail them out next time.
> 
> the space will be immediately be used by others, and thus will defeat
> the alleged purpose of giving them private space with which to stitch
> together 1918 customers.
> 
> it will cement in and perpetuate the n-level ipv4 nat model.

to be clear, without this space, the people who think nat444 is a good
idea will do it anyway using either their existing space or rfc1918
space. the conditions where it actually helps (e.g. by reducing the
likelyhood of collision are) at the margins.

> randy
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 09 Nov 2010 17:21:54 +1300

Dave,

On 2010-11-09 17:09, David Conrad wrote:
> I'm confused, but that may be because of lack of information.
> 
> Ignoring for the time being the advisability of doing this, if we're talking about a new pseudo-RFC 1918 block, why is it going to a regional registry?  Presumably its use would be global.  Shouldn't it be a direct allocation by IANA as a result of IETF action?

http://en.wikipedia.org/wiki/End_run

    Brian

> Regards,
> -drc
> 
> On Nov 8, 2010, at 6:01 PM, Randy Bush wrote:
>

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 9 Nov 2010 00:26:21 -0500

Folks,

I am having a strange sense of déjà vu. About two years ago, we saw another proposal to allocate a /8 for private use to support another transition mechanism. We concluded:

- that we didn't have a /8 to spare
- that a /8 wouldn't be enough, anyway

So, the proposal was abandoned. I wonder if we are not in the exact same place today.

Maybe the equation would be changed if we could make do with a /16, but it appears that a /16 wouldn't help.

                                           Ron
                                           <speaking as individual contributor>

BTW, the LISP WG is talking about asking for a prefix for a very similar reason.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of james woodyatt
> Sent: Monday, November 08, 2010 11:50 PM
> To: IPv6 Operations; [email-masked]; [email-masked]
> Subject: Re: [v6ops] Heads up
> 
> On Nov 8, 2010, at 20:24 , Erik Kline wrote:
> >
> > Didn't Akira Nakagawa/KDDI present something like this a few meetings
> ago?  I can't recall clearly...
> 
> It was in Chicago, if I recall correctly.  At which point Tony Hain
> joked that we should direct IANA to just turn over the entire remaining
> free pool for that use.
> 
> Personally, I'd prefer to take Tony's suggestion as a serious proposal.
> A single /8 isn't enough, is it?  For NAT444 to be a really workable
> architecture, we've got to give over enough addresses that service
> providers can handle at least a hundred million subscriber addresses in
> the same address realm, right?
> 
> 
> --
> james woodyatt <[email-masked]>
> member of technical staff, communications engineering
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 09 Nov 2010 19:08:35 +1300

Ron,

On 2010-11-09 18:26, Ronald Bonica wrote:
> Folks,
> 
> I am having a strange sense of déjà vu. 

That is common when one is playing whack-a-mole.

This particular game will end, according to today's prediction, on 25-Jan-2012.

    Brian

About two years ago, we saw another proposal to allocate a /8 for private use to support another transition mechanism. We concluded:
> OPS-AREA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ops-area
>

---

From: Arturo Servin <[email-masked]>
Date: Tue, 9 Nov 2010 07:23:21 -0200

Not sure if IANA can issue something shorter than a /8.

-as

On 9 Nov 2010, at 06:34, Christopher LILJENSTOLPE wrote:

> Greetings,
> 
> 	Fred, I think, mis-typed.   The request would go to IANA.  The space, to answer the other question is either /10 or /12.
> 
> Chris
> 
> On 09Nov2010, at 15.21, Brian E Carpenter wrote:
> 
>> Dave,
>> 
> Christopher LILJENSTOLPE    Telstra    o +61 3 8647 6389
> pgp key https://www.asgaard.org/~cdl/cdl.asc
>

---

From: Arturo Servin <[email-masked]>
Date: Tue, 9 Nov 2010 13:23:22 -0200

I should have said, "longer" than a /8.

	Thanks for the offline comments about it.

Regards,
-as

---

From: Fred Baker <[email-masked]>
Date: Tue, 9 Nov 2010 10:29:46 +0800

Chris Liljenstolpe has a proposal that he made in ops-area today, for a mechanism to create what amounts to an RFC 1918 prefix, but specifically for use in NAT444 ISP configurations. It involves a request to the ARIN board. He will write a quick draft and post it this week, discuss this Thursday in the Ops WG, and call the question in Friday's v6ops meeting. Due to the real time nature of the discussion, I'll ask folks to be aware and follow it.

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 8 Nov 2010 22:58:23 -0500

what size prefix ? A /8 ? /16 ?

> Chris Liljenstolpe has a proposal that he made in ops-area today, for a mechanism to create what amounts to an RFC 1918 prefix, but specifically for use in NAT444 ISP configurations. It involves a…

Regards
Marshall

---

From: Randy Bush <[email-masked]>
Date: Tue, 09 Nov 2010 12:01:02 +0800

randy

---

From: David Conrad <[email-masked]>
Date: Mon, 8 Nov 2010 18:09:38 -1000

Regards,
-drc

---

From: Erik Kline <[email-masked]>
Date: Tue, 9 Nov 2010 13:24:12 +0900

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 8 Nov 2010 20:49:53 -0800

> it will cement in and perpetuate the n-level ipv4 nat model.

Agreed.  It is bad architecture and bad strategy at every level.  My
own path toward IPv6 only started when i gave up on the  Class E for
private networks pipe dream.

Cameron

---

From: james woodyatt <[email-masked]>
Date: Mon, 08 Nov 2010 20:50:24 -0800

On Nov 8, 2010, at 20:24 , Erik Kline wrote:
> 
> Didn't Akira Nakagawa/KDDI present something like this a few meetings ago?  I can't recall clearly...

It was in Chicago, if I recall correctly.  At which point Tony Hain joked that we should direct IANA to just turn over the entire remaining free pool for that use.

Personally, I'd prefer to take Tony's suggestion as a serious proposal.  A single /8 isn't enough, is it?  For NAT444 to be a really workable architecture, we've got to give over enough addresses that service providers can handle at least a hundred million subscriber addresses in the same address realm, right?

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 8 Nov 2010 21:06:43 -0800

> Personally, I'd prefer to take Tony's suggestion as a serious proposal.  A single /8 isn't enough, is it?  For NAT444 to be a really workable architecture, we've got to give over enough addresses t…

I need at least 10x /8s to number my current network, and that does
not account for growth.

Verizon Wireless uses 40+ instances of 10.0.0.0/8

Cameron

---

From: "George, Wes E IV [NTK]" <[email-masked]>
Date: Tue, 9 Nov 2010 05:44:52 +0000

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Fred Baker
Sent: Tuesday, November 09, 2010 10:30 AM
Subject: [v6ops] Heads up

>Chris Liljenstolpe has a proposal that he made in ops-area today, for a
mechanism to >create what amounts to an >RFC 1918 prefix, but specifically
for use in NAT444 ISP configurations. It involves a request to the ARIN
board. >He will write a quick draft and post it this week, discuss this
Thursday in the Ops WG, and call the question in >Friday's v6ops meeting.
Due to the real time nature of the discussion, I'll ask folks to be aware
and follow it.

I don't understand why we're writing *another* draft about this. Others have
mentioned the other drafts that are floating around (and being shot down),
but here they are:
http://zinfandel.levkowetz.com/html/draft-weil-opsawg-provider-address-space
-02
http://tools.ietf.org/html/draft-shirasaki-isp-shared-addr-05 

Use one of those, add any arguments that they have not already covered.

However, I like others who have posted am very much against this idea. 
I have yet to see a good explanation as to why we should squander such a
limited resource because multiple sets of 1918 space is hard to manage, and
squatting on unannounced legacy space (DoD and others) so that you have a /8
or two to play internally with is equal parts risky and evil. It's a bad
situation, but this doesn't solve it.

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ronald Bonica

>BTW, the LISP WG is talking about asking for a prefix for a very similar
reason.

And I told *them* it was a bad idea too. 

Wes George

---

From: Dave Thaler <[email-masked]>
Date: Tue, 9 Nov 2010 05:54:11 +0000

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Cameron Byrne
> Sent: Tuesday, November 09, 2010 1:07 PM
> To: james woodyatt
> Cc: IPv6 Operations; [email-masked]; [email-masked]
> Subject: Re: [OPS-AREA] [v6ops] Heads up
> 
> > It was in Chicago, if I recall correctly.  At which point Tony Hain joked that we
> should direct IANA to just turn over the entire remaining free pool for that use.
> >
> > Personally, I'd prefer to take Tony's suggestion as a serious proposal.  A single
> /8 isn't enough, is it?  For NAT444 to be a really workable architecture, we've
> got to give over enough addresses that service providers can handle at least a
> hundred million subscriber addresses in the same address realm, right?
> 
> I need at least 10x /8s to number my current network, and that does not
> account for growth.
> 

The draft was http://tools.ietf.org/html/draft-shirasaki-nat444-isp-shared-addr-04

This isn't specific to ISPs either, there's pain any time you're connected to multiple
address domains.  So another example would be the address space used by VPNs.
If it conflicts with the address space of the location you're in, things break.
So I had responded saying there's nothing particularly unique to ISPs here.
If you give a space to ISPs be prepared to give one for other categories as well
such as VPNs.

And if I remember correctly, ARIN had already rejected the 
draft-shirasaki-nat444-isp-shared-addr request, so Chris Liljenstolpe
writing another draft and asking ARIN would seem to be redundant.

-Dave

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Tue, 9 Nov 2010 19:34:46 +1100

Greetings,

Chris

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Tue, 9 Nov 2010 19:35:53 +1100

Ahh, no James.  We can multiplex the space.  It does mean that there is some potential stranding on the public space, but that is manageable. 

	Chris

> Personally, I'd prefer to take Tony's suggestion as a serious proposal.  A single /8 isn't enough, is it?  For NAT444 to be a really workable architecture, we've got to give over enough addresses t…

---
李柯睿
Check my PGP key here:
https://www.asgaard.org/~cdl/cdl.asc

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Tue, 9 Nov 2010 19:49:15 +1100

Greetings Randy,

> it is a hack which perpetuates their kludge and does not help ipv6 one

Randy - no one WANTS to run NAT444, however, some of us don't see a way around running it for some period of time.  To ignore this means that customer v4 will break, or we do a massive churn in our customer networks.  What's done is done, we are where we are.  (the collective "We") need to find a way out of the mess, and this gives us some time to fix things.
> they'll want some other silliness to bail them out next time.

I don't intend to do this INSTEAD of transition (nor do I think that any of the authors do),  we intend to do this to ease the transition
> the alleged purpose of giving them private space with which to stitch

However, customers who do do that will  not be doing it under direction of the industry.  It's an easier case.
> it will cement in and perpetuate the n-level ipv4 nat model.

That is the last model that I want to perpetuate Randy - please don't attribute agendas to me that I don't have.

---

From: John Curran <[email-masked]>
Date: Tue, 9 Nov 2010 08:33:57 -0500

> http://en.wikipedia.org/wiki/End_run

Not likely to happen.

While ARIN does stand by to assist if relevant, we would be unlikely to consider the matter without prior guidance from the IESG and IANA directing such (since allocation of specialized technical space is the realm of the IETF & IANA...)

FYI,
/John

John Curran
President and CEO
ARIN

---

From: David Conrad <[email-masked]>
Date: Tue, 9 Nov 2010 07:33:46 -1000

> 	Not sure if IANA can issue something shorter than a /8.

Yes they can.  They can't allocate anything longer than a /8 to an RIR, but any prefix length is fair game for a direct allocation as a result of IETF action.  For example, see the 6to4 IPv4 anycast assignment.

Regards,
-drc

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Nov 2010 15:43:31 +1300

> I know that some believe that purposely breaking the IPv4 service could be a way to promote IPv6.

I don't believe that, and I don't doubt the good intentions of the
people proposing this - I've seen too much of them in v6 working groups
for that. The problem is elsewhere: this would be a very strong message
to ISPs that are *not* actively planning v6 support that here is a way
to evade the issue for many more years. So we end up with a bigger
legacy of customers stuck behind NAT444 and ISPs that have no intention
to move forward.

I would like to be proved wrong.

Regards
   Brian

On 2010-11-11 15:30, Rémi Després wrote:
> Hi, Ron,
> 
> 
> Le 9 nov. 2010 à 13:26, Ronald Bonica a écrit :
> - Allocating a /8 to ISPs, while it is still feasible, would only slightly modify the date at which IPv4 prefixes er exhausted, not a big deal.
>  
> - ISPs already operate several parallel instances of 10/8 clouds, so that, although a /7 would be more generous than better a /8, a new /8 is enough to replace current 10/8's by a prefix private sites don't uses internally.
> 
> The known reason why ISPs have problems if they assign 10/8's is that some NAT44s:
>  . assign 10/8's for internal use
>  . cannot work with identical internal and external address spaces 
> 
> CONCLUSION:
> Assigning a new /8 to ISPs so that they can replace 10/8:
> - is easy to do
> - has negligible effect on the transition schedule
> - does solve a real problem
> It should, in view of this analysis above, be highly recommended by IETF
> 
> I know that some believe that purposely breaking the IPv4 service could be a way to promote IPv6.
> IMHO, their time would be better spent working to eliminate IPv6 limitations than militating against IPv4 deserved QoS.
> 
> Kind regards,
> RD
> 
> 
> 
> 
>

---

From: Rémi Després <[email-masked]>
Date: Thu, 11 Nov 2010 10:30:47 +0800

Hi, Ron,

 

CONCLUSION:

Kind regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Thu, 11 Nov 2010 11:03:16 +0800

Le 11 nov. 2010 à 10:43, Brian E Carpenter a écrit :

> for that. The problem is elsewhere:

> this would be a very strong message
> to evade the issue for many more years.

I don't see this at all.
No one can have doubt that I help ISPs to plan native IPv6 "service".

IMHO, ISPs that ask for this prefix would rather interpret the message as:
"We IETF don't care about your view of your real ISP problems. We use to solve OUR problems, and wish to continue to do so."
I don't say, it is what you mean, I just say that this interpretation seems to me legitimate.

> So we end up with a bigger

NAT444 customers are IMHO less a problem than those that prematurely use IPv6 with partially broken solutions.

ISP cooperation is needed to cleanly deploy IPv6.
Having respect for their legitimate requests seems to me the best path toward clean IPv6 everywhere.
(I don't think we will be stuck if we do what we have to.)

Regards,
RD

---

From: Erik Kline <[email-masked]>
Date: Thu, 11 Nov 2010 12:13:44 +0900

Hypothesis: Anything meant to extend the usefulness of IPv4 that does
not /simultaneously put immense pressure on the thousands of big and
small things that block IPv6 deployment/ will not result in IPv6
readiness nor IPv6 deployment.

It may extend the life of IPv4, giving more time for the blocking
elements to become more IPv6-ready, but how will this time be
different from the status quo for the last 10+ years?  The only thing
that could possibly be different is that the free blocks will actually
be gone by the end of 2011.  But if that doesn't work, it's impossible
for me to see how these sorts of proposals won't result in anything
other than "business as usual".

Most animals are motivated to either move toward pleasure or away from
pain.  Align incentives, or readjust expectations, accordingly.

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 11 Nov 2010 11:28:29 +0800

> No one can have doubt that I help ISPs to plan native IPv6 "service".

Ipv4 service is going to get worse. natting it at the carrier level, is
inevitable as it is today in many of our enviroments. and as an operator
I don't fundamentaly see the difference regarding what addresses are on
the inside and outside of the nat, each one is an event horizon. some
customers are going to experience breakage, in the form of their
existing cpe failing at some point along the way.

As operators we have a fiduciary responsbility to our business, our
customers and the oganizations of which we are member's from which we
secure addresses, to:

A - use them judiciously
B - secure the resource we need to support business growth

I happen to disagree that this prefix is necessary, not because I think
that providers shouldn't use nat444 as one of the tools in their
arsenal. I didn't support it in the rir's and I don't support it here.

It's possible that with sufficient thrust disagreement can be overcome,
that's fine but the argumentation in favor of it either in the rir's or
here has been strictly unconvincing as far as I'm concerned,  I don't
belive that special use ipv4 blocks assigned at this late date are in
the interests of existing or future ip address users. We have enough
cruft of that form in ipv4 already.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Nov 2010 16:31:06 +1300

Rémi,

I think you miss my point.

Announcing a new ambiguous prefix will be misunderstood by the ISPs
who are ignoring IPv6 as a clear invitation to continue ignoring IPv6
and serve their new customers, badly, using NAT444 indefinitely.

That is my concern here.

Regards
   Brian

---

From: "Soininen, Jonne (NSN-FI/Espoo)" <[email-masked]>
Date: Thu, 11 Nov 2010 05:22:41 +0200

Hi,

I'd like to add a different perspective. We basically have seven /8s left
(plus the five that will be given directly to the RIRs when we come down to
that number). I think the world expects everybody to be as responsible as
possible with those last available /8s.

Taking a /8 to RFC1918bis space means that it is away from global address
space use. If we want to do that we have to be really, really sure this is
the right thing to do. IETF would really have to have strong consensus on
it.

I seriously doubt we can converge to any consensus before the IANA pool is
empty. 

Just a thought.

Cheers,

Jonne.

> Hypothesis: Anything meant to extend the usefulness of IPv4 that does
not
> /simultaneously put immense pressure on the thousands of big and
small things
> that block IPv6 deployment/ will not result in IPv6
readiness nor IPv6
> deployment.

It may extend the life of IPv4, giving more time for the
> blocking
elements to become more IPv6-ready, but how will this time
> be
that
> could possibly be different is that the free blocks will actually
be gone by
> the end of 2011.  But if that doesn't work, it's impossible
for me to see how
> these sorts of proposals won't result in anything
other than "business as
> usual".

Most animals are motivated to either move toward pleasure or away
> from

On 11
> November 2010 11:43, Brian E Carpenter
<[email-masked]> wrote:
>> Hi,
>>> I am having
> a strange sense of déjà vu. About two years ago, we saw another proposal to
> allocate a /8 for private use to support another transition mechanism. We
> concluded:
>>>
>> - Allocating a /8
> to ISPs, while it is still feasible, would only slightly modify the date at
> which IPv4 prefixes er exhausted, not a big deal.
>>
>>> - that a /8 wouldn't
> be enough, anyway
>>
>> - ISPs already operate several parallel instances of
> 10/8 clouds, so that, although a /7 would be more generous than better a /8, a
> new /8 is enough to replace current 10/8's by a prefix private sites don't
> uses internally.
>>
>>  . cannot
> work with identical internal and external address spaces
>>
>> CONCLUSION:
>>
>> - is easy to
> do
>> I know that some believe that purposely breaking the
> IPv4 service could be a way to promote IPv6.
>> IMHO, their time would be
> better spent working to eliminate IPv6 limitations than militating against
> IPv4 deserved QoS.
>>
>> Kind regards,
>> RD
>>
>>
>>
>>
>>
>>> So, the
> proposal was abandoned. I wonder if we are not in the exact same place
> today.
>>>
>>> Maybe the equation would be changed if we could make do with a
> /16, but it appears that a /16 wouldn't help.
>>>
>>>                        
>                   Ron
>>>                                           <speaking
>>>> It was in Chicago, if
> I recall correctly.  At which point Tony Hain
>>>> joked that we should direct
> IANA to just turn over the entire remaining
>>>> free pool for that
> use.
>>>>
________________________________
> _______________
v6ops mailing
> list
[email-masked]

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34
E-mail: [email-masked]

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Thu, 11 Nov 2010 14:57:32 +1100

Brian,

	We are doing everything that we can to signal that this is part of our transition, not instead of.  I don't know how much more clear we can be.

	Chris

---
李柯睿
Check my PGP key here:

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 10 Nov 2010 19:58:19 -0800

> pain.  Align incentives, or readjust expectations, accordingly.

Very stongly agree here.  10 years to roll out IPv6 is a long time.
How is now different from before? At my network, we ran out of IPs in
2007 and tried every trick in the book to try to number users in light
of IPv4 exhaust, RIR rejections, and exponential edge growth.  We had
pain, so we moved.

Only after realizing IPv6 was the only path out of this mess did we
serious take on IPv6.

For the NAT444, LSN, CGN folks. Come on in the waters fine, pick a
bogon up at the door and let your corporate risk management group know
where you are going, they will help you muster up a business case for
real v6 (CPEs for 6rd of whatever).  It's the new normal cost of doing
business with a growing edge.

The good new for the slow to deploy is that IPv4 is not going
anywhere. The sky is not falling for existing users.  There is no such
thing as maintstream IPv6-only content, and wont be for a long time.

Your only concern now is how do you roll out new services and new
users with no IPv4, and now your LSN or your IPv6 plans are tied to
customer acquisition costs and new service enablement cost.  Running
out of IPv4 does not impact business as usual in the near term with no
edge growth, it impacts incremental adds.... incremental adds are now
stuck with a new cost, it pretty standard business case structure to
fund an ipv6 project when framed this way.

Cameron

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Thu, 11 Nov 2010 14:57:32 +1100

Brian,

	Chris

>>>> the same address realm, right?

- ---
李柯睿
Check my PGP key here:

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Thu, 11 Nov 2010 15:16:24 +1100

Joel,

> cruft of that form in ipv4 already.

it's not an event horizon, because there is a forwarding engine that joins those two horizons.

	Chris

> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
> 

---
李柯睿
Check my PGP key here:

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Thu, 11 Nov 2010 15:16:24 +1100

Joel,

	Chris

- ---
李柯睿
Check my PGP key here:

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Thu, 11 Nov 2010 15:22:38 +1100

Cameron,

> Only after realizing IPv6 was the only path out of this mess did we

We are deadly serious on IPv6, you must not have listened to the discussion.

> business with a growing edge.

Wonderful idea - corporate risk management assisting with IPv6 transition - I though we had problems....
> fund an ipv6 project when framed this way.

We already have that business case done, and have been executing on it.

- ---
李柯睿
Check my PGP key here:

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Thu, 11 Nov 2010 15:18:55 +1100

A nit here, but the ask is for a /10.

- ---
李柯睿
Check my PGP key here:

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Thu, 11 Nov 2010 15:16:24 +1100

- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Joel,

	Chris

>>>>>> the same address realm, right?

- - ---
李柯睿
Check my PGP key here:

- -----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJM225oAAoJEGmx2Mt/+Iw/bXAH/0A3JWglsFizo3Zjc41MDQW2
XOLZVtiBDQoM5Vn9Ig+zPgwq/LZo3ZGoNXTGkJOowhq748AZBZhYmqy2tjwIukMG
+fLWD8KvJlZNryw1aipa9gAibtdv/AFKAkfdZx0TRGqAtuGXqXa9sx2c+8Lc9quy
opeHe4Gdcvv1vU675tuFFAoc1+bxVQGT4/f9r1eKb9iZytBiSWh+ioGKHyM0xmt0
K/A+9eqQhnuT/qAZn+1opl11Qz5yJAZADF4THagOyaSPpStkhX/6ynkcRZ0t5KpX
s0R37xXrdsOlNgRAsD53IFbtbFIZidknIxY19uijSIStrT5p21pOS8pqyZH/XxY=
=H1Ua
- -----END PGP SIGNATURE-----

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Thu, 11 Nov 2010 15:14:24 +1100

Erik,

> readiness nor IPv6 deployment.
Interesting hypothesis, but seems to me to be a bit of A=B, C=D A=D?  Everyone who is asking for this is running as fast as they can to get v6 deployed.  Sometimes reality is messier than a hypothesis

> other than "business as usual".

Glad you used BAU = IPv6 is our BAU engineering and product model.  However, some operators have infrastructure that is a bit longer in the tooth than others....  There are rules of physics, economics, and support systems.  

> pain.  Align incentives, or readjust expectations, accordingly.

So, what animal did you have in mind for us, a sloth?  

- - ---
李柯睿
Check my PGP key here:

iQEcBAEBAgAGBQJM225RAAoJEGmx2Mt/+Iw/DpEIAInK9tQsTxLMjOEM68R36pyw
nYlv8n7rbY/Q/TIyDxjzBr0Z3tHYRnzA2ATVVNRIWNm+K31ROsq8LUUY6gQvKrJv
lZRBCnKhKi+2XmcfaWf5kfZVwE9wjtEh6E02FSE/lc7usJ+sl2wsGvglEur/IP3b
76piaDVm38gDeY59myCpCFdqMFyzeRIBUo1SVHl2kIuUaI7zTQt5ygS+7d6GW5TG
EQodM8BJMttNTCxhDb79YtGer5t6td2+uZ1inqjNumXoqiIK/ghvDwrPwJMTg8U3
rsChKYXMxDALH1Ar32LeRrZQbqL6t2G+YxD+tf+6abKIOfjast5/V4UetAZ6gPU=
=hEtQ
- -----END PGP SIGNATURE-----

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 10 Nov 2010 20:54:30 -0800

On Wed, Nov 10, 2010 at 8:14 PM, Christopher LILJENSTOLPE
<[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

Large network operators all around the world have already hit this.
They use duplicate addressing, vrf's, NAT444,  or other messy things
like bogons.  This is old news.  Folks have been complaining about
RFC1918 being too small for a long time.  Folks tried to open up class
E, no luck.  With every day that goes buy, expanding RFC1918 yields
less and less utility as more and more network operators work around
it.  Sorry you are hitting this wall now, but this is really just old
news (as you may have heard)

Cameron

ps.  glad you are doing ipv6.

> -----BEGIN PGP SIGNATURE-----
>
> iQEcBAEBAgAGBQJM23BGAAoJEGmx2Mt/+Iw/y98IAJbq3DtZW58CNBuQMtqyVdFr
> rWnb3peQnwXe8jedlllZWqeJ3KDF0nx2uBYXVQX7QakxvHO/xlWejN+Le7XYwb4H
> k8NlK0XwPMC4sZxQDq8Jh5X63iPMrFEl+GC0h9DNmvQ5jF8IuWnaCgDQE7BSAnSJ
> M+gQHWbZzD/yCxl0+MhE3jvCL1xFN4YpzPPGXUFtr9h/eZ/8rANegRgLHXNpA4Ur
> icAhza9yA7RCdLnWZHQpktmrGmyIOoHwkOUQo5G/T8ChV6RvwsYDndZzrm3F8Xzf
> fa6Sa5CLnCH2UvOEmC+SkgP02pXl00X7J7kUlGoYEp4moEemZJxY889t/6LFQt0=
> =Alp6
> -----END PGP SIGNATURE-----

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Thu, 11 Nov 2010 14:57:32 +1100

Brian,

	Chris

- - ---
李柯睿
Check my PGP key here:

iQEcBAEBAgAGBQJM22rVAAoJEGmx2Mt/+Iw/kV8H/29NeUY2sfbiRG/TElfRlUC0
/Mtv43JjSSgFSwOAtEqyF/biffefKa2GAFrnLBax/zD+MHzKUSvNwONnwq6a9q42
OQzFrwlbK1IkVs+sUw/Zs1HERsTNvTWQJd0p6Df3OMuuqs3GmmGGkLGUCkAwSyj4
iw30gRv7+J6nn7RCSx50nVPJgynF6nm+NGHiJDOLSKoPF7lceJLI/wCKPF+zcW6T
VmA/cGQGb6gtxuzJlObpe5TslxcBXPXpe1JD1caCHgk0/i7MSQtNCoeIe0KvnFi0
4zVVJLYRmy7tv384plE7rcu6Wb7vBi8bQSNW+fqAeN5Rvdz3vI5FFfodZjstsVs=
=BZWf
- -----END PGP SIGNATURE-----

---

From: james woodyatt <[email-masked]>
Date: Wed, 10 Nov 2010 21:15:43 -0800

On Nov 10, 2010, at 19:31, Brian E Carpenter wrote:
> 
> Announcing a new ambiguous prefix will be misunderstood by the ISPs who are ignoring IPv6 as a clear invitation to continue ignoring IPv6 and serve their new customers, badly, using NAT444 indefinitely.

I share that concern, and I have some technical misgivings too.

In particular, I think it's worth noting that "Connection of IPv6 Domains via IPv4 Clouds" [RFC 3056] makes what would now be regarded as a *normative* reference to "Address Allocation for Private Internets" [RFC 1918].

Adding a new address prefix for supporting NAT444 operators would require A) revising RFC 3056 to add the prefix explicitly to the set of IPv4 address ranges that MUST NOT appear in the V4ADDR field of 6to4 addresses, and B) updating all globally deployed 6to4 hosts and routers accordingly.  If you don't do that, then subscriber gateways with 6to4-router functions and other 6to4-enabled hosts will mistakenly expect that 6to4 addresses with NAT444-reserved V4ADDR fields are globally scoped when they are not.  Some 6to4-routers will happily advertise such prefixes on their local network links, and most existing hosts today will stateless autoconfigure IPv6 interface address and proceed to expect native IPv6 service to the public Internet over a broken 6to4 tunnel.  Some older implementations will prefer the broken 6to4 default route over the NAT444 default route.

A second consideration also comes to mind.  Dynamic port-forwarding services, e.g. NAT-PMP and UPnP-IGD, are typically incompatible with NAT444 (unless somebody has hauled off and implemented I-D.woodyatt-spnatpmp-appl without telling me).  Some [most?, *all*?] operating systems with application service interfaces that use these dynamic port-forwarding services in some kind of dirty UNSAF [RFC 3424] system aimed at registering the exterior address for a server in a directory of some kind, e.g. DNS-SD, would need to be upgraded to handle the NAT444-reserved prefix the same as they currently handle RFC 1918 prefixes.

The way I see it: NAT444 proponents don't have a good story for coping with a whole bunch of related problems, i.e. 6to4, NAT-PMP/UPnP-IGD, etc, all swirling around address realm foo.

This latest proposal for a NAT444-reserved private prefix doesn't really help solve any of them.  Sure, it let's the NAT444 operators avoid an address realm conflict between subscriber local networks and provider networks, but it only does so at the expense of further operational complications related to UNSAF systems that have hard-coded the prefixes defined currently in RFC 1918 and would need to be upgraded to cope.

On balance, I don't see the point of explicitly marking out the prefix at the IANA level.  What good do we imagine that would do beyond what could simply be had by having the NAT444 operators conspire to choose a globally-addressable prefix from among one of their own allocations?  Do we imagine that host and router implementors will respond to the new IANA allocation by rushing out software upgrades to everything in the world that knows about private address prefixes?  If you're one of those people, then I'd like to introduce you to some senior executives for system software engineering I know.  I think you'll be enlightened by the experience of explaining your concerns to them.

---

From: "STARK, BARBARA H (ATTLABS)" <[email-masked]>
Date: Thu, 11 Nov 2010 00:45:11 -0500

There seems to be some sort of weird assumption that if this block is not allocated, then ISPs won't do NAT444. 

FYI: Whether or not this block gets allocated, ISPs will do NAT444. The same ISPs currently planning on it will do it, anyway. The allocation of this block won't change that.

However, NAT444 will have to be done with greater care, because of higher risks and support costs associated with using 10.x.x.x. Which means more resources will have to be applied to doing NAT444. And where will those resources come from? Why, from IPv6 transition, of course!

IMO, not providing this IPv4 address block will actually slow down IPv6 deployments, because more resources will be required to make sure the introduction of NAT444 is done "right". Resources knowledgeable about IP networks are finite. Help desk resources are finite.

Please don't kid yourselves that you have the power to prevent NAT444 from happening by denying this request. ISPs don't base their business models around IETF being sympathetic to the needs of mass market consumers. We have 10.x.x.x, and it can be made to work -- it'll just require more resources to do so. What the IETF can do, is make this aspect of the overall transition easier (and less resource intensive), so that we can get on with the business of deploying IPv6. 

It's unfortunate that IETF wants to slow down IPv6 deployment by forcing ISPs to put more resources on NAT444, but so be it.
Barbara

---

From: james woodyatt <[email-masked]>
Date: Wed, 10 Nov 2010 22:11:15 -0800

On Nov 10, 2010, at 21:45, STARK, BARBARA H (ATTLABS) wrote:
> 
> IMO, not providing this IPv4 address block will actually slow down IPv6 deployments, because more resources will be required to make sure the introduction of NAT444 is done "right".

How will directing IANA to allocate the NAT444 block speed up IPv6 deployment?

Operators that go down the NAT444 rabbit hole will have to divert a lot of resources away from IPv6 whether the [non-RFC1918] space they use is allocated by IANA or by the RIRs or by a shadowy cabal in a Chinatown tavern.  The problems they'll face using private address realms with non-RFC1918 space will be the same regardless of who allocates the space.

What advantage is there in directing *IANA* to do it?  I don't see it.  I see only the downsides, which Mr. Carpenter has already mentioned, and I see no upside.

---

From: Erik Kline <[email-masked]>
Date: Thu, 11 Nov 2010 15:01:46 +0900

> It's unfortunate that IETF wants to slow down IPv6 deployment by forcing ISPs to put more resources on NAT444, but so be it.

I'm not sure this logic stands up in the light of the experiences of
those who have tried NAT444 and chosen to do something else.

For those contemplating NAT444, what's wrong with NAT464?  In theory
that middle "4" represents a single, logical administrative domain,
no?

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 10 Nov 2010 22:12:45 -0800

> FYI: Whether or not this block gets allocated, ISPs will do NAT444. The same ISPs currently planning on it will do it, anyway. The allocation of this block won't change that.

Agreed.  When you built yourself into a corner, you are in a corner.

> However, NAT444 will have to be done with greater care, because of higher risks and support costs associated with using 10.x.x.x. Which means more resources will have to be applied to doing NAT444.…

Umm, yes the pain is a stick for the internet collectively not having
the gumption to have this serious transition action 5 years ago ( i
was not rolling out v6 5 years ago).... to the early actors go the
spoils (carrots),  If the economic incentives are not there, nothing
will happen.  This is all that we have learned from the last 10 years
of IPv6 non-deployment.

And, your assumption that NAT444 resources take from IPv6 resources
sounds a little off.

Business cases i have seen show current state (overlapping addresses,
bogons, ..,.) and then future state (ipv6, long sandy beaches, ...)
and talk how we can invest X to get to future state which, while
spending money now, but will save us a ton later on (thank you NPV
calculator) and insulate us from business continuity issues.

Your scenario, as i understand it, is that we have current state,
current state is a death spiral, doom and gloom forever until
bankruptcy.  Unless, we take valid IPv4 addresses and give them to
your middle box.

> It's unfortunate that IETF wants to slow down IPv6 deployment by forcing ISPs to put more resources on NAT444, but so be it.

Wow.

---

From: Victor Kuarsingh <[email-masked]>
Date: Thu, 11 Nov 2010 14:29:27 +0800

On 11/11/10 2:11 PM, "james woodyatt" <[email-masked]> wrote:

>> IMO, not providing this IPv4 address block will actually slow down IPv6
>> deployments, because more resources will be required to make sure the
>> introduction of NAT444 is done "right".
> 

We have found problems in deploying NAT444 with RFC1918.  The same resources
(as with many operators) can work on fixing those problems (as stated
previously) or work on IPv6. (I would like to work on IPv6).

> 
> Operators that go down the NAT444 rabbit hole will have to divert a lot of
> resources away from IPv6 whether the [non-RFC1918] space they use is allocated
> by IANA or by the RIRs or by a shadowy cabal in a Chinatown tavern.  The
> problems they'll face using private address realms with non-RFC1918 space will
> be the same regardless of who allocates the space.
> 
> What advantage is there in directing *IANA* to do it?  I don't see it.  I see
> only the downsides, which Mr. Carpenter has already mentioned, and I see no
> upside.
> 
> 
> --

---

From: "STARK, BARBARA H (ATTLABS)" <[email-masked]>
Date: Thu, 11 Nov 2010 01:25:19 -0500

> that middle "4" represents a single, logical administrative domain,

Existing home routers/gateways don't support NAT464. I need for the router vendors to focus on implementing a top-notch, full IPv6 stack. The less work they have to do for legacy IPv4, the better. NAT444 requires no new code in the home gateway, allowing them to put their resources on doing IPv6 right.
Barbara

---

From: Roger Jørgensen <[email-masked]>
Date: Thu, 11 Nov 2010 07:31:36 +0100

On Thu, Nov 11, 2010 at 3:30 AM, Rémi Després <[email-masked]> wrote:
>> I am having a strange sense of déjà vu. About two years ago, we saw another
>> proposal to allocate a /8 for private use to support another transition mechanism.
>> We concluded:
>>
> - Allocating a /8 to ISPs, while it is still feasible, would only slightly modify the date
> at which IPv4 prefixes er exhausted, not a big deal.
>
> - ISPs already operate several parallel instances of 10/8 clouds, so that, although
> a /7 would be more generous than better a /8, a new /8 is enough to replace
> current 10/8's by a prefix private sites don't uses internally.
>
<snip>

I'm still pretty young compared to most here, only close 15years in the Internet
game but I've already seen enough to be scared of suggestions like the one
that started this.

You're conclusion and the suggestion only make the matter worse really.
You put of the problem into the future instead of solving it.
If the problem is as bad as everyone say, why not make it 50 x 10.0.0.0/8
instead of 40 x ? (someone said something about verizon had used over 40).
You have the adresses, you know how to do it, just do it _and_ at the same
time deploy IPv6.

When you've painted yourself into a corner, why also point the walls around
you just because you are in a corner?

-- 

Roger Jorgensen           |
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: "George, Wes E IV [NTK]" <[email-masked]>
Date: Thu, 11 Nov 2010 07:35:24 +0000

> It's unfortunate that IETF wants to slow down IPv6 deployment by forcing 
> ISPs to put more resources on NAT444, but so be it.
> Barbara
[Wes] I'm not convinced by the hyperbole. NAT444 is hard and is going to take 
lots of resources regardless of what block you use for your internal range, 
and IPv6 deployment is not optional if you'd like to stay in business. There 
are lots of us in the same boat, and it's not an either/or decision. We're 
behind, and we're playing catch-up. The IETF shouldn't be the scapegoat for 
that.

Erik Kline said:
I'm not sure this logic stands up in the light of the experiences of those who 
have tried NAT444 and chosen to do something else.

[Wes] those = ? Something else = ? Are you referring to Cameron's comments 
about bagging it in favor of NAT64? I'm not aware of anyone with a legacy set 
of IPv4-only devices that they need to keep functional for some nonzero amount 
of time coming up with a magic solution that doesn't involve NAT444, changes 
on the host that aren't possible, or copious amounts of global address space 
that won't be available. If there is, I'd love to hear it. Barbara is right 
about one thing, nothing will change the fact that NAT444 is going to be 
required for legitimate business reasons, mainly that it's cheaper and quicker 
than throwing hardware at the problem to turn over your entire device pool 
rapidly instead of waiting for it to happen on an upgrade cycle.

Erik Kline said:
For those contemplating NAT444, what's wrong with NAT464?  In theory that 
middle "4" represents a single, logical administrative domain, no?

[Wes]
What's wrong with NAT464 is that NAT64 (whether there's a 4 in front of it or 
not) requires the device sitting at the boundary of the "4s" to speak IPv6. 
Trust me, I'd love to have a network full of devices that can do Native IPv6 
so that I could seriously consider NAT64 as a solution. But I don't, and I 
won't soon enough to make that a realistic solution.

That said, I am not in favor of allocating a specific block to do NAT444 with. 
It's a waste of resources. Due to the fact that we've gone from originally 
asking for a /8 to a /10, and there are folks who would need much more space 
than even one /8 for it to actually solve their problem, it simply doesn't 
help enough. Most of the intended users would still have to have multiple 
overlapping regions of this block just like they'd have to do if they used 
RFC1918, so literally the only problem this solves is the assertion that 
RFC1918 is not usable because of overlap with CPE devices that use it on their 
inside network and the risk of customer impact that generates.

Don't like that risk? I'll quote Cameron: "For the NAT444, LSN, CGN folks. 
Come on in the waters fine, pick a bogon up at the door"

Though I seriously doubt that IETF will officially sanction squatting on 
unrouted public space for internal NAT as a solution to this problem, people 
are currently (and will continue) doing this. It's ugly, risky, unholy, and 
generally "regarded as harmful" but most of the time it works. And though 
there will be financial incentive to find unused IPv4 space (thereby reducing 
the amount of Bogon available) there are plenty of legacy address holders that 
have no intention of either giving back/selling their space or making it 
visible on the Internet anytime soon.

Wes George

---

From: "George, Wes E IV [NTK]" <[email-masked]>
Date: Thu, 11 Nov 2010 07:47:52 +0000

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of 
Victor Kuarsingh
Sent: Thursday, November 11, 2010 2:29 PM
To: james woodyatt; IPv6 Operations; [email-masked]; [email-masked]
Subject: Re: [v6ops] [OPSAWG] Heads up - Plea for allocating a /8 to ISPs

>We have found problems in deploying NAT444 with RFC1918.

[Wes]
I'm not going to pretend that this works perfectly, but be specific about the 
problems you've found. Not a general discussion of what NATs or multiple 
layers of NATs break - specifically what does using RFC1918 as a CPE NAT 
device's external interface break? That needs to be in the draft to contribute 
to the technical justification for this proposed allocation. Or, it needs to 
be in http://tools.ietf.org/html/draft-donley-nat444-impacts-01 with a 
reference to it from this draft.

The one that I'm aware of is the overlap between internal and external address 
blocks (i.e. they can't be the same). Regarding this, the quote I heard (from 
someone, can't remember whom) was, "we have tested this and we can find at 
least one CPE device that uses every address block within RFC1918 on their 
internal network segment".

I would like to see some hard evidence to back up this claim, and at the /24 
level, not at the supernet level. I assume it's available if it's been tested.
I think that what you'll find is that if you line the spread up based on 
number of devices and deployment numbers within each network, there will be a 
bell curve, and the solution is actually to avoid the most common ones and 
manage the breakage on the ones that are out at the long tail. I think it's 
acceptable to have a fractional percentage of customers that need to have a 
tech support person talk them through reconfiguring their router to use a 
different network block to fix things, or even replacing their customer-owned 
router with an ISP-owned (and hopefully IPv6-capable) one. As Joel and the 
draft above said, the other reality here is that NAT444 is *going* to break 
things. Why is it verboten for it to break a small percentage of CPE because 
the vendor in question decided to be different and use 10/8 as its default 
internal network?

Wes George

---

From: james woodyatt <[email-masked]>
Date: Thu, 11 Nov 2010 00:10:31 -0800

> previously) or work on IPv6. (I would like to work on IPv6).

That doesn't answer the question.  For clarity, I asked the same question twice, worded a little differently the second time.  Here it is again...

>> What advantage is there in directing *IANA* to do it?

I understand why you want to use a prefix not listed in RFC 1918.  I don't understand why getting it from IANA will be any better for you than if you get it from Joe's House Of IPv4 Addresses.

---

From: Victor Kuarsingh <[email-masked]>
Date: Thu, 11 Nov 2010 16:27:54 +0800

On 11/11/10 4:10 PM, "james woodyatt" <[email-masked]> wrote:

> That doesn't answer the question.  For clarity, I asked the same question
> twice, worded a little differently the second time.  Here it is again...
> 
> I understand why you want to use a prefix not listed in RFC 1918.  I don't
> understand why getting it from IANA will be any better for you than if you get
> it from Joe's House Of IPv4 Addresses.
> 
The goal here was that in aggregate, the provides use less global space for
a common use. It is more efficient for providers to share a block, then all
go to the RIRs and ask for their own slice.

Victor

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Thu, 11 Nov 2010 19:43:13 +1100

> that middle "4" represents a single, logical administrative domain,

One word - CPE.  When I have the CPE out there, it can be 464, DSLite, IVI, etc.  The problem is BEFORE I get the CPE fleet changed out.  Read the drafts

---
李柯睿
Check my PGP key here:

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Thu, 11 Nov 2010 19:45:55 +1100

> that middle "4" represents a single, logical administrative domain,

Only one thing - CPE.  If I had CPE that could do NAT464, I would, of course, do NAT464 - I'm not an idiot after all.  Let's see, do NAT464 using a small part of my v6 block of addresses, or go through two years of pain trying to get this draft through.  Once I have that CPE, I can do 464, DSLite, (d)IVI, etc.  Before I get the CPE flieet swaped out, I don't have 464.  Read the drafts again, please.

	Chris

---
李柯睿
Check my PGP key here:

---

From: "George, Wes E IV [NTK]" <[email-masked]>
Date: Thu, 11 Nov 2010 08:48:15 +0000

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Rémi Després
Sent: Thursday, November 11, 2010 4:34 PM
To: Soininen, Jonne (NSN-FI/Espoo)
Cc: IPv6 Operations; [email-masked]; [email-masked]
Subject: Re: [v6ops] Heads up - Plea for allocating a /8 to ISPs

Unless I miss something, the proposal is not at all to add a 4th prefix to
the 3 of RFC1918.
It is only that one /8 be neither in the global address space nor in the
private address space of RFC 1918. 
Thus, ISPs can use it in place of the 10/8 they use today, and thus
eliminate conflicts with some of the customer sites that use 10/8.
One /8 is necessary AND SUFFICIENT to do this.

[Wes]
Yes, you miss something. First, this has already been changed from a /8 to a
/10, which may change your opinion of sufficient.
And saying "it's not part of 1918" is splitting hairs if it's being used in
the same way. 
>From RFC1918:
Hosts within enterprises that use IP can be partitioned into three
   categories:
[snip]
      Category 2: hosts that need access to a limited set of outside
                  services (e.g., E-mail, FTP, netnews, remote login)
                  which can be handled by mediating gateways (e.g.,
                  application layer gateways). For many hosts in this
                  category an unrestricted external access (provided
                  via IP connectivity) may be unnecessary and even
                  undesirable for privacy/security reasons. Just like
                  hosts within the first category, such hosts may use
                  IP addresses that are unambiguous within an
                  enterprise, but may be ambiguous between
                  enterprises.
[snip]
For security reasons, many enterprises use application
           layer gateways to connect their internal network to the
           Internet.  The internal network usually does not have
           direct access to the Internet, thus only one or more
           gateways are visible from the Internet. In this case, the
           internal network can use non-unique IP network numbers.
[snip]
An enterprise that decides to use IP addresses out of the address
   space defined in this document can do so without any coordination
   with IANA or an Internet registry. The address space can thus be used
   by many enterprises. Addresses within this private address space will
   only be unique within the enterprise, or the set of enterprises which
   choose to cooperate over this space so they may communicate with each
   other in their own private internet.

Wes George

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Nov 2010 21:51:07 +1300

> On 11/11/10 4:10 PM, "james woodyatt" <[email-masked]> wrote:

...
> go to the RIRs and ask for their own slice.

That isn't quite the question, I think. So let me answer the actual
question: What advantage is there in directing *IANA* to do it?

The answer is in RFC 2650 "Memorandum of Understanding Concerning the
Technical Work of the Internet Assigned Numbers Authority".

Under this agreement, the IETF *can* direct IANA to allocate
IP address space for technical purposes. See the subclause (b)
in clause 4.3. There is no other route by which the IETF can
direct IANA to allocate address space, and the IETF certainly
can't direct the RIRs in any way whatever.

So to answer James, the advantage is that the IETF *can*
direct IANA, but the IETF can't direct the RIRs.

I don't believe the IETF *should* do this, but as the initial
drafter and a signatory of the MoU published as RFC 2650,
I thought I should clarify what's really going on here. Getting
this proposal through IETF consensus and IESG approval would
result in a direct order to IANA.

    Brian

.

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Thu, 11 Nov 2010 19:56:02 +1100

Greetings James,

> Adding a new address prefix for supporting NAT444 operators would require A) revising RFC 3056 to add the prefix explicitly to the set of IPv4 address ranges that MUST NOT appear in the V4ADDR fiel…

That is an impact, agreed.

> The way I see it: NAT444 proponents don't have a good story for coping with a whole bunch of related problems, i.e. 6to4, NAT-PMP/UPnP-IGD, etc, all swirling around address realm foo.

We never said that NAT444 did.  In fact, we said it's broken.  However, NAT444 WILL happen, the CPE fleet out there isn't ready for anything else.  The question is, do you want to have residential gateways / routers to have conflicting addresses on either side of the NAT function, or not?  That's the what this block is intended to deal with.

> This latest proposal for a NAT444-reserved private prefix doesn't really help solve any of them.  Sure, it let's the NAT444 operators avoid an address realm conflict between subscriber local networ…

See above
> On balance, I don't see the point of explicitly marking out the prefix at the IANA level.  What good do we imagine that would do beyond what could simply be had by having the NAT444 operators consp…

We could do that - but guess what, we'd all do it - there goes the rest of the pool.  I don't think that's what most of the community wants.  I think the only thing that needs to be updated, based on a new "private" block, is, from what you say, is 6to4.  Yes, it's an impact of 444, one of many.  However, if we're throwing around senior software engineering executives, maybe we should introduce them to the concept of testing the continuity of a link before bringing up a route or tunnel, rather than just seeing if a magic address is present on a device.  Just a thought....

---
李柯睿
Check my PGP key here:

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Thu, 11 Nov 2010 19:57:57 +1100

James,

	You missed the statement - NAT444 WILL happen.  If the block is present, it will be less complex to deploy and manage - leaving more resources for other things.  If I have address conflict problems, more resources will have to be directed to those.  Not granting the block does not forstall NAT444.

---
李柯睿
Check my PGP key here:

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Thu, 11 Nov 2010 19:58:39 +1100

> previously) or work on IPv6. (I would like to work on IPv6).
+1

---
李柯睿
Check my PGP key here:

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Thu, 11 Nov 2010 20:02:45 +1100

Hi Roger,

> You have the adresses, you know how to do it, just do it _and_ at the same

The problem statement is NOT we are out of 1918 address space.  Please re-fresh your memory of the draft.  The problem is that the customer base uses pretty much all of 1918 address space on their side of their NAT gateways, I can not find a block that I can guarantee would not conflict with a customers use of 1918.  If Murphy strikes (and he will) and I assign, say 172.16.32.5/24 to the upstream interface of a CPE, with the default router of 172.16.32.1/24; and the customer has configured his side of the CPE to be 172.16.32.254/24, the routing stack in the CPE will become hopelessly confused.  Which interface to send traffic to 172.16.32.1?  Both are valid connected routes.

---
李柯睿
Check my PGP key here:

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Thu, 11 Nov 2010 20:07:02 +1100

Greetings James,

> I understand why you want to use a prefix not listed in RFC 1918.  I don't understand why getting it from IANA will be any better for you than if you get it from Joe's House Of IPv4 Addresses.

It's simple, operators out of at least 2 of the 5 RIR regions are saying they need this.  I would bet that operators in all RIR regions would use this if available (heads pulled in after the bruising battle this has been in the past).  As it is "global" it does not seem fair to ask one RIR to sacrifice for the rest.  If you are not talking RIR, then transfer policies make that pretty much a one-way street for the donor.

---
李柯睿
Check my PGP key here:

---

From: Marco Hogewoning <[email-masked]>
Date: Thu, 11 Nov 2010 09:41:46 +0100

> Unless I miss something, the proposal is not at all to add a 4th prefix to the 3 of RFC1918.
> It is only that one /8 be neither in the global address space nor in the private address space of RFC 1918. 
> Thus, ISPs can use it in place of the 10/8 they use today, and thus eliminate conflicts with some of the customer sites that use 10/8.

And won't solve a thing as within days people start using it like it's 10/8. Oh, I'm merging two companies, address conflict, know what let's use XX/8. For more examples, see the work of Geoff Huston and others on the traffic in 1/8. People weren't supposed to use that one as well.

MarcoH
(no hats)

---

From: Rémi Després <[email-masked]>
Date: Thu, 11 Nov 2010 16:18:49 +0800

> arsenal. I didn't support it in the rir's and I don't support it here.

Fair enough.
ISPs aren't all the same.

But you won't be hurt if some others use this new /8 prefix.

My point isn't that all ISPs  should use it.
It is only that those that ask for it have a valid reason to do so.
I se no good reason to refuse it. 
(The idea that this would demotivate them to offer also IPv6 seems to me insulting to their ability to understand the situation.)

> the interests of existing or future ip address users.

My impression is that you negate that 10/8 used for both internal and external addresses creates problems with some NATs.
AFAIK, this is a sad fact, but a fact.

Regards,
RD

> We have enough

---

From: Rémi Després <[email-masked]>
Date: Thu, 11 Nov 2010 16:33:57 +0800

Le 11 nov. 2010 à 11:22, Soininen, Jonne (NSN-FI/Espoo) a écrit :

> space use.

RD

---

From: Erik Kline <[email-masked]>
Date: Thu, 11 Nov 2010 17:46:36 +0900

> One word - CPE.  When I have the CPE out there, it can be 464, DSLite, IVI,
> etc.  The problem is BEFORE I get the CPE fleet changed out.  Read the
> drafts
>
> no?

Yeah, I wasn't thinking clearly.  The middle "N" (either 4 or 6)
bridges the ISP-controlled administrative domain and the Wild, Wild
West that is home devices.

---

From: "George, Wes E IV [NTK]" <[email-masked]>
Date: Thu, 11 Nov 2010 09:15:54 +0000

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Christopher LILJENSTOLPE
Sent: Thursday, November 11, 2010 4:56 PM
To: james woodyatt
Cc: IPv6 Operations; [email-masked]; [email-masked]
Subject: Re: [v6ops] [OPS-AREA] Heads up - Plea for allocating a /8 to ISPs

We could do that - but guess what, we'd all do it - there goes the rest of
the pool.  I don't think that's what most of the community wants.  
 
[Wes]  I believe what he was suggesting was that one of you goes for a block
and you all use the same one instead of trying to get IETF to do it. 
However, let's call your response what it is - a mostly empty threat. Given
that ultimately we are all being driven by what's best for our own
businesses (since we like being employed), methinks you're overplaying your
altruism a bit. If you could have justified a /8 (or a /10, etc) of address
space, you'd already have it. Let's remember that you already have addresses
for your current customers, so this is only about new customers who are
using old non-IPv6-capable CPE that they brought with them. How long do we
let that practice go before we simply say, sorry this is too old? Software
developers eventually drop support for old OS and hardware combinations.
Same with my 5 year old Linksys box - no software updates are available
anymore. Why should we expect any different for network operators? 

I will concede that the one exception here would be the mobile operators,
who today are doing significant amounts of oversubscription of IP addresses
because their users aren't always on. As that changes, they need more
addresses. And for them, it's probably not an empty threat. But as I've
said, they wouldn't be able to use a single /10 to solve that problem
either, and assumedly they have control over more of the CPE that talks to
the network, so the RFC1918 conflict argument isn't nearly as much of an
issue.

Wes George

---

From: Tore Anderson <[email-masked]>
Date: Thu, 11 Nov 2010 10:44:58 +0100

* Christopher LILJENSTOLPE

> We could do that - but guess what, we'd all do it - there goes the
> rest of the pool.

Christopher,

If you have a justified need for a /10 in your network today, you should
feel free to go ahead and request it from your favourite RIR. It's OK,
really.  Others operators are already doing so (i.e. 50.128/9), and if I
were you I would not wager my business continuity on there being
anything left in the IANA pool for the implementation of this proposal
when it eventually reaches consensus.

Thanks for being altruistic and all, but in the end it doesn't really
matter one way or the other.  Regardless of what you do or don't do,
it'll all be gone in a few months.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27

---

From: Rémi Després <[email-masked]>
Date: Thu, 11 Nov 2010 17:51:05 +0800

Thanks, James, for this detailed explanation.

It has a substantial technical content, something that, IMHO, has been missing so far in this discussion.

Actually, I am now convinced that if ISPs would use a reserved /8 where they use a 10/8 today, they would create new problems possibly even worse than the solved one.

I therefore change my mind and no longer support the idea of a new reserved /8.

Best regards,
RD

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Thu, 11 Nov 2010 21:04:37 +1100

Thank's for the clarity, Brian.

	Chris

---
李柯睿
Check my PGP key here:

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Thu, 11 Nov 2010 21:08:04 +1100

Thank's Tore, I think.

We all are here to keep this engine going.  By doing that, I help me, but am egregiously wasteful in the whole.  In turn, that impacts the total, and therefore, me.

	Chris

---
李柯睿
Check my PGP key here:

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Thu, 11 Nov 2010 21:10:23 +1100

Marco,

	You are missing the point - just like most of the folks.  This is NOT to increase the size of 1918, but set aside a space to do this.  Yes, people will poach it, but they would be off the reservation.  Most users are scattered all over 1918 because we told them to, default (or example) configurations put them there, manuals instructed them on how to do it, etc.  The draft says not to do any of that.  It will be a tractable problem.

	Chris

---
李柯睿
Check my PGP key here:

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Thu, 11 Nov 2010 21:11:23 +1100

You are correct Rémi. Actually, we are asking for less than the /8

---
李柯睿
Check my PGP key here:

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Thu, 11 Nov 2010 21:13:53 +1100

> ISPs aren't all the same.

Exactly

> It is only that those that ask for it have a valid reason to do so.

We would either have a valid reason for doing so, or be completely psychotic, given the amount of pain that this road has been.
> (The idea that this would demotivate them to offer also IPv6 seems to me insulting to their ability to understand the situation.)

Thank you, Rémi.

> AFAIK, this is a sad fact, but a fact.

It is sad, and true
Chris

---
李柯睿
Check my PGP key here:

---

From: Erik Kline <[email-masked]>
Date: Thu, 11 Nov 2010 19:31:47 +0900

> You are correct Rémi. Actually, we are asking for less than the /8

http://tools.ietf.org/html/draft-weil-shared-transition-space-request-01  right?

My apologies for missing it, but where is the discussion which
determines the size for which you're asking?  Is that from here
http://tools.ietf.org/html/draft-shirasaki-isp-shared-addr-05  (not
referenced from your -01, I think, but 2 links away)?

Frankly, I'm not sure why you wouldn't just go ahead and ask for a /8.
 Despite all the views for and against, if this happens you'll
probably only get one shot at it.  _shrug_

---

From: Tore Anderson <[email-masked]>
Date: Thu, 11 Nov 2010 11:32:25 +0100

> We all are here to keep this engine going.

That's futile.  It'll run dry and stop, either tomorrow or the day after
tomorrow.  Those that have not already prepared will get in trouble,
regardless of how you go about obtaining your /10.

> By doing that, I help me, but am egregiously wasteful in the whole.
> In turn, that impacts the total, and therefore, me.

There's nobody stopping you from getting your /10 now and then inviting
the rest of the NAT444 operators to squat on it instead of getting their
own.  The end result would be the same, but you won't have to risk not
getting the necessary IETF consensus by the time IANA runs out.

Best regards,

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Thu, 11 Nov 2010 21:45:43 +1100

> regardless of how you go about obtaining your /10.

By engine, I meant the Internet, not v4 the way we do it today.  Please, PLEASE try and flush the cache state that says the authors do not want to do v6.

> getting the necessary IETF consensus by the time IANA runs out.

And why should APNIC bear the "tax" for everyone else?

---
李柯睿
Check my PGP key here:

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Thu, 11 Nov 2010 21:55:47 +1100

Greetings Mark,

On 11Nov2010, at 21.50, Mark Smith wrote:

> On Thu, 11 Nov 2010 15:18:55 +1100
> Christopher LILJENSTOLPE <[email-masked]> wrote:
> 
> Being from the same market as you, is the fundamental motive because
> customers own CPE, and therefore you (we) can't "force" them to upgrade
> it to support IPv6?
> 
> It seems to me we have a three option solution to the "customer owns the
> CPE problem" - carrot, stick, or subversive.
> 
> "Carrot" being, we / the Internet provides some sort of "killer app"
> for IPv6, and therefore people ask for it/install it.
> 
> "Stick" being, at some point in time, the costs of dealing with things
> like CGN, to the customer, become higher than the cost of migrating to
> IPv6. Something like a helpdesk call that is answered with "If you
> upgrade to IPv6, the problem will go away" or something similar.
> 
> "Subversive" being, we manage to get them to upgrade to IPv6 without
> realising it (shiny new CPE which they're happy with because it's
> newer / they've satisfied their "new stuff addiction" problem that most
> of us seem to suffer from ;-) ) (which is pretty much the carrot option,
> except that the carrot option is the one where they know what they
> want, and therefore specifically ask for IPv6 (possibly without
> actually understanding what it is they're asking for)).
> 
> While I do think the NAT444 option has value, I also do think it is
> also fundamentally delaying the inevitable "Stick" option. In my
> experience, the sooner you suffer the pain, the less you suffer over
> all. ISPs with customer owned CPE are probably going to wear pain
> regardless, it's all about the degree ...

Even if we started deploying the stick earlier this year, there are too many targets to get the fleet changed before we're out.  It's just too big a problem space.  We will do carrot/stick/subversion, but it will take time.

	Chris

>> iQEcBAEBAgAGBQJM23AEAAoJEGmx2Mt/+Iw/KiEH/36K/YzJSdrWCPqMwmR1PACx
>> QP1vqpW1fIADwQ+WHrC9ua1X6RAf9LI6+cjrVcYnfZsZXw/zJibWC6TgNZt0exA3
>> iHxhXqEzjy6rd/y6ATkLDDbu75YXU8SfHm08SozFaEw6aIw3tmHTymxnRQiN3x/7
>> v6FKwst5Mc7/S+mwCIcQLwBgtw/+ZntrhUaZOMsCmyyv6UdziFiub7YBdplODzNK
>> EDdUCXaLOwqY2RAAw0DvHtTY/f9s9UeX1GBhBb8THBQmH7hKJIZ8IK99aAV10tHU
>> axD270Yr2YPIPnfMbqM88zhEs/DT77WGZGmo7zQ/6A9150S83M27i251hLeNyZs=
>> =6t41

---
李柯睿
Check my PGP key here:

---

From: Mark Smith <[email-masked]>
Date: Thu, 11 Nov 2010 21:20:08 +1030

---

From: Mark Smith <[email-masked]>
Date: Thu, 11 Nov 2010 21:27:02 +1030

Off list. Knowing who Christopher is currently working for/with,
and no offence to him, because I don't know how long he has worked
there, his organisation know all about 1/8, because I've seen his
organisation ask for 1/8 to be turned into an RFC1918 address at an
IPv6 conference a few years ago - and I've been at another ISP on the
receiving end of being asked to announce it to them for nothing more
than monitoring purposes. Geoff Huston used to work for them for a quite
while too ;-)

(Australia is a pretty small place :-) )

On Thu, 11 Nov 2010 09:41:46 +0100

---

From: Lindqvist Kurt Erik <[email-masked]>
Date: Thu, 11 Nov 2010 12:11:38 +0100

> go to the RIRs and ask for their own slice.

To make sure I understand this - then the opposite should also be true. That if a /10 is given for this, a lot of address space could be returned to the RIRs free pools?

Best regards,

- kurtis -

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Thu, 11 Nov 2010 23:23:38 +1100

Well Mark, that wasn't much of an off-list.  I won't take offense, however.  Yes, I do work for 1221.  I've been there for 18 months, and am not familiar with your reference to 1/8 for Telstra.  The only knowledge I have of 1/8 at 1221 is that we just got a chunk of it from APNIC in our latest assignment.  Not sure what you are referring to about "announcing" 1/8 to 1221 for monitoring purposes, was this when Geoff was there?  We have been making similar requests for a while.

Yes, it is.

	Chris

---
李柯睿
Check my PGP key here:

---

From: Chris Donley <[email-masked]>
Date: Thu, 11 Nov 2010 07:31:13 -0700

Not quite...a lot of address space that is justified under RIR allocation policies (est. 60 million addresses) would not be allocated for this purpose in the future.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lindqvist Kurt Erik
Sent: Thursday, November 11, 2010 4:12 AM
To: Victor Kuarsingh
Cc: IPv6 Operations; james woodyatt; [email-masked]; [email-masked]
Subject: Re: [OPSAWG] [v6ops] Heads up - Plea for allocating a /8 to ISPs

On 11 nov 2010, at 09.27, Victor Kuarsingh wrote:
>> I understand why you want to use a prefix not listed in RFC 1918.  I 
>> don't understand why getting it from IANA will be any better for you 
>> than if you get it from Joe's House Of IPv4 Addresses.
>> 
> The goal here was that in aggregate, the provides use less global 
> space for a common use. It is more efficient for providers to share a 
> block, then all go to the RIRs and ask for their own slice.

Best regards,

- kurtis -

---

From: Tore Anderson <[email-masked]>
Date: Thu, 11 Nov 2010 13:08:00 +0100

> By engine, I meant the Internet, not v4 the way we do it today. 
> Please, PLEASE try and flush the cache state that says the authors
> do not want to do v6.

Christopher,

I have never said, nor believed, that the you or any of the other
authors do not want or intend to do IPv6.

What I am saying is that whether you and the other authors in sum
allocate, say, a /6 for your own private interim NAT444 purposes,
instead of the shared /10, it's not going to make much of a difference
to either IPv4 depletion or IPv6 deployment.  It seems to me that the
effort you're putting into getting the shared /10 is way out of
proportion compared to the minimal benefits it'd bring.

>> There's nobody stopping you from getting your /10 now and then 
>> inviting the rest of the NAT444 operators to squat on it instead
>> of getting their own.  The end result would be the same, but you
>> won't have to risk not getting the necessary IETF consensus by the
>> time IANA runs out.
> 

Because that would be in accordance with the already established
policies for distribution of IPv4 addresses.  If you need the addresses,
go ask for them.  That's what everyone has been doing for years and have
agreed upon as being the fair way to do it.  I must say I find it quite
puzzling that you're so insistent on not doing so this time, too.

Besides, assuming you got your IANA /10, and if Geoff Huston's
projections are correct, APNIC would end up paying the «tax» anyway as
they looks set to be the one to make the last allocation from IANA which
would then be an incomplete /8.  Or perhaps AfriNIC, if instead Stephan
Lagerholm turns out to be correct?  Or any of the other three RIRs, who
knows?  When we're out of addresses it won't be «fair» anyway so this
«tax» concern is meaningless, in my opinion.

Best regards,

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 11 Nov 2010 13:00:40 +0000

On 11/11/2010 11:11, Lindqvist Kurt Erik wrote:
> To make sure I understand this - then the opposite should also be true.
> That if a /10 is given for this, a lot of address space could be
> returned to the RIRs free pools?

Without meaning to sound overly optimistic, I would fully expect this to 
happen - shortly after hell freezes over.

Nick

---

From: Victor Kuarsingh <[email-masked]>
Date: Fri, 12 Nov 2010 00:41:28 +0800

Jason,

I would have to disagree with that position.  In our case, it would be
exactly the opposite.  The non-RFC1918 block would replace public addresses,
therefore the same class of security policy applies.

Using RFC1918 (other then the other technical reasons given as to what it¹s
problematic) would require more uplifts of security polices, ACLs, and
network related configuration.

I think the points is it is provider by provider dependant.  If the provide
historically used RFC1918 for addressing, then perhaps in that case it would
be as you said, but this is definitely not true for providers that current
supply public space to endpoints (until we run out of course).

Regards,

Victor

On 12/11/10 12:24 AM, "Jason Lin" <[email-masked]> wrote:

> hi,
> 
> Considering currently security policies that have been deployed in the
> network, the new reserved /8 prefix may lead to not only re-design the
> security policies, but also reconfigure the related nodes which has high risk.
> 
> so, my point is negative.
> 
> Jin Yan Lin
> China Telecom
> 
> 
> On Fri, Nov 12, 2010 at 12:15 AM, Gert Doering <[email-masked]> wrote:
>> Hi,
>> 
>> On Thu, Nov 11, 2010 at 04:18:49PM +0800, Rémi Després wrote:
>> Sure.  Someone else might have a good use for a /22 that they can't
>> get because the last /8 was taken away for NAT444 services.
>> 
>> Especially content providers will need small bits of IPv4 space to
>> provide content to large masses of not-yet-IPv6 capable eyeballs.
>> 
>> Against this proposal.
>> 
>> Gert Doering
>>         -- NetMaster
>> --
>> did you enable IPv6 on something today...?
>> 
>> SpaceNet AG                        Vorstand: Sebastian v. Bomhard
>> Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
>> D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
>> Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Gert Doering <[email-masked]>
Date: Thu, 11 Nov 2010 17:15:10 +0100

Hi,

Against this proposal.

Gert Doering
        -- NetMaster

---

From: Jason Lin <[email-masked]>
Date: Fri, 12 Nov 2010 00:24:24 +0800

hi,

Considering currently security policies that have been deployed in the
network, the new reserved /8 prefix may lead to not only re-design the
security policies, but also reconfigure the related nodes which has high
risk.

Jin Yan Lin
China Telecom

---

From: Jason Lin <[email-masked]>
Date: Fri, 12 Nov 2010 01:15:08 +0800

Victor,

Yes, I miss the important constrain "in some case". :)

Actually, I'm worry about the situation like this:
(Assuming the new reserved space is 5.x.x.x/8)

Currently: (in some case)

          /---------------------------\
        <    ISP Backbone      >    non-RFC1918 can be routed in backbone,
so it includes 5.x,x,x/8
          \--------------------------/
            /                       \
[  MAN 1 ]       ...    [ MAN X]       RFC1918 may be routed in some MAN

Cheers!

Jin Yan Lin
China Telecom

On Fri, Nov 12, 2010 at 12:41 AM, Victor Kuarsingh <
[email-masked]> wrote:

> Using RFC1918 (other then the other technical reasons given as to what it’s
> ------------------------------

---

From: bill manning <[email-masked]>
Date: Thu, 11 Nov 2010 10:07:33 -0800

Over a decade ago, when RFC 1918 was being discussed, I suggested that it might make more sense to use the address space reserved
by RFC 1918 for the Public Internet and use the remainder of the address space for internal networking purposes.
Invert the RFC 1918 model.   This sounds like a others are finally coming around to this idea, but are only looking at it in a piecewise, incremental
fashion.

--bill

On 11November2010Thursday, at 8:41, Victor Kuarsingh wrote:

> Jason,
> 
> I would have to disagree with that position.  In our case, it would be exactly the opposite.  The non-RFC1918 block would replace public addresses, therefore the same class of security policy applies.
> 
> Using RFC1918 (other then the other technical reasons given as to what it’s problematic) would require more uplifts of security polices, ACLs, and network related configuration.
> 
> I think the points is it is provider by provider dependant.  If the provide historically used RFC1918 for addressing, then perhaps in that case it would be as you said, but this is definitely not true for providers that current supply public space to endpoints (until we run out of course).
> 
> Regards,
> 
> Victor
> 
> 
>> Considering currently security policies that have been deployed in the network, the new reserved /8 prefix may lead to not only re-design the security policies, but also reconfigure the related nodes which has high risk.
>>

---

From: james woodyatt <[email-masked]>
Date: Thu, 11 Nov 2010 10:23:18 -0800

On Nov 11, 2010, at 00:51, Brian E Carpenter wrote:
> 
> [...] The answer is in RFC 2650 "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority". [...] So to answer James, the advantage is that the IETF *can* direct IANA, but the IETF can't direct the RIRs.[...]

Thus Mr. Carpenter exposes an ambiguity in the question I posed.  I should have asked what is the *technical* advantage to be gained by obtaining a direction from IETF to IANA for a proposed NAT444-reserved non-global space, and how would that technical advantage promote a smoother or faster transition to IPv6?

I understand that operators have a thorny political problem complicating the technical problems involved in NAT444 deployment.  They don't like using RFC1918 space because it conflicts with subscriber address realms.  So, they feel the need to use non-RFC1918 space (and live with the breakage thereby done to 6to4, NAT-PMP, UPnP-IGD, dynamic DNS, et cetera).  The political problem is that none of them want to be the ones to give up their hard-won global allocation from a RIR for the good of the tribe.  The same political problem arises at the level of the NRO, i.e. none of the registries want to give up *their* hard-won numbers to promote the global welfare.  So, now the NAT444 operators are here at the IETF [again] asking us to do what NRO won't do.

But IETF doesn't have the authority to direct IANA to allocate numbers for *political* purposes.  We need a technical problem to solve.  Hence, my annoying questions, which so far have gone unanswered.

Let's take a trip down memory lane, back to the ancient days before RFC 1918.  Even before its predecessor, RFC 1597, there were networks on private address realms.  Does anyone here remember how we settled on the prefixes that IANA assigned for private networks in RFC 1597?

The Internet community did a survey and found the three most common unallocated prefixes that were already in use at the time.  Those became what IANA reserved.  The key point here is that IETF could point to a good technical reason for pulling those prefixes out of the global free pool: they were already in use by a lot of existing private address realms, and directing IANA to reserve those blocks explicitly would allow future systems to distinguish private and global addresses from one another.

If service providers want IETF to deny the NRO another block of scarce IPv4 address space, for a purpose similar but not identical to the purpose described in RFC 1918, then they're going to need a good technical reason for it-- because the terms of RFC 2650 demand it.  So, let's hear it.

I very much would like to hear how the proposal under discussion is intended to allow future CPE systems to *use* the fact that IANA has reserved a new prefix for them.  Note well: I'm not interested in hand-waving about what legacy CPE with current software loads will do.  I'm concerned about future systems here, and I suspect the NAT444 proponents have a very naïve view of how CPE system implementors are likely to react to a new IANA reservation, prior to its uptake by operators.

A more effective way to get CPE implementors to recognize the NAT444 prefix is to pick one and start using it.  Then, when systems break under NAT444 with intermediate realms using non-RFC1918 space, as you have been planning all along, the CPE vendors may-- depending on how important the damage is to *them*-- be induced to fix them somehow, most likely by adding one or more NAT444 prefixes to their software to be treated as non-global addresses.  Once *that's* done, operators should come back to IETF and say, "Here are the prefixes we poisoned for global use by using them to support NAT444 operations.  Please direct IANA to reserve them so that the next release of FreeBSD can safely stop treating them like they might be valid global addresses somewhere."

---

From: james woodyatt <[email-masked]>
Date: Thu, 11 Nov 2010 11:14:32 -0800

> It's simple, operators out of at least 2 of the 5 RIR regions are saying they need this.  I would bet that operators in all RIR regions would use this if available (heads pulled in after the bruisi…

The draft is asking for IETF to direct IANA to deny the NRO access to some currently unallocated prefix and declare it a new kind of special-use prefix.  I wonder what the NRO thinks about that, given that their mission explicitly includes the protection of the free pool from barbarians.

It's important, because you haven't made an *engineering* case yet for why this prefix needs to be a special-use reservation by IANA as opposed to an ordinary one allocated by the usual method to some organizational vehicle created for the purpose, i.e. The NAT444 Operators Group, Inc.

Moving on.  The draft uses RFC 2119 normative keywords despite being categorized as Informational.  It places exactly one "requirement" on CPE implementations: "Network equipment manufacturers MUST NOT use the assigned block in default or example device configurations."  This is a pointless requirement.  There is no real danger of this ever happening with ordinary global addresses currently in the free pool.  The rest of the "requirements" in the draft are equally pointless for the same reason.

Moreover, Section 3 "Motivation" makes it clear that the operational consideration here is not about future CPE gateway devices anyway.  It's about legacy devices, *none* of which use any of the address prefixes currently in the IANA free pool in default or example configurations.  Therefore, the requirements do not follow from the motivation.

I fail to see why NAT444 operators, as a group, need IETF to deny a perfectly good global IPv4 prefix to the NRO, when an ordinary global allocation to an assigned special entity would suffice for the purposes in question.

---

From: Roger Jørgensen <[email-masked]>
Date: Thu, 11 Nov 2010 21:53:01 +0100

On Thu, Nov 11, 2010 at 11:50 AM, Mark Smith
<[email-masked]> wrote:
<snip>
> regardless, it's all about the degree ...

It is really that simple... and it is far easier to just face it now and get
over with it than to put it off into some undefined future when you
anyway will have other problems to deal with.

No matter what option is chosen now, if _will_ hurt. You're only
option it really when you want the pain. We lost the no-pain options
quite some years ago :(

-- 

Roger Jorgensen           |

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Fri, 12 Nov 2010 12:42:35 +1100

Jason,

	The issue is that the operators using this block would NOT leak 5.x.x.x/8 out of their network, so it's routable on THEIR backbone, but not the broader network.  In fact, the CPE would see it, but nothing else should.  There should be no 5.x.x.x/8 visible from any customer network, other than the CPE.

	Chris

---
李柯睿
Check my PGP key here:

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Fri, 12 Nov 2010 12:33:39 +1100

Summary of the proposal - adverse possession (i.e. squatters' rights) with the 444 operators being the desseisor?

	Chris

---
李柯睿
Check my PGP key here:

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Fri, 12 Nov 2010 12:38:44 +1100

You are correct, Victor.   The end-user should treat the 444 block just as they would treat other foreign, globally unique blocks as far as security policies are concerned (routing policy, however, would probably want to treat it as bogon).

	Chris

---
李柯睿
Check my PGP key here:

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Fri, 12 Nov 2010 12:38:44 +1100

Chris

- ---
李柯睿
Check my PGP key here:

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Fri, 12 Nov 2010 12:46:25 +1100

Gert,

	The risk is that many of the authors then go and suck up much more than the /10 to do the same thing, using globally unique space, when it really doesn't need to be globally unique.  It's wasteful, and the authors are trying to conserve as much as possible, while not blanking a large amount of heritage IPv4 space.  Many of us were hoping to get to DSLite, NAT464, IVI before this happened, but we are out of time, and the infrastructure (in this case CPE) isn't ready at scale in a format that most of us can consume and put into production in the remaining time.

	Chris

---
李柯睿
Check my PGP key here:

---

From: Victor Kuarsingh <[email-masked]>
Date: Fri, 12 Nov 2010 10:06:31 +0800

Chris,

Agreed, but I don’t see that as a big engineering task.  Also, its the same
task not matter what block I use that is non-RFC1918 (IANA
assigned/reserved, squat, or my own RIR assigned used for this purpose).

Regards,

Victor

On 12/11/10 9:38 AM, "Christopher LILJENSTOLPE" <[email-masked]> wrote:

> You are correct, Victor.   The end-user should treat the 444 block just as
> they would treat other foreign, globally unique blocks as far as security
> policies are concerned (routing policy, however, would probably want to treat
> it as bogon).
> 
> Chris
>

---

From: "George, Wes E IV [NTK]" <[email-masked]>
Date: Fri, 12 Nov 2010 02:36:33 +0000

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Christopher LILJENSTOLPE
Sent: Friday, November 12, 2010 9:46 AM

The risk is that many of the authors then go and suck up much more than the
/10 to do the same thing, using globally unique space, when it really
doesn't need to be globally unique.  It's wasteful, and the authors are
trying to conserve as much as possible, while not blanking a large amount of
heritage IPv4 space.  Many of us were hoping to get to DSLite, NAT464, IVI
before this happened, but we are out of time, and the infrastructure (in
this case CPE) isn't ready at scale in a format that most of us can consume
and put into production in the remaining time.

[Wes]
Chris, you haven't given any sound reasoning as to why you are going to
suddenly need a significant amount of additional IPv4 space that makes me
believe the concept "if you tell us no, we'll just go get a bunch more
routable space and empty the table" is anything but a rhetorical flourish.
1) you have enough space for your current customer base, or else you'd
already be in this situation and have figured out a solution *
2) if you seriously expect your customer base to grow *dramatically* (eg
enough to justify a large block of global space at an RIR), why are you
assuming that it will be with old CPE? Churn from one provider to another
where people bring their old kit isn't likely to drive you to need 4M
addresses. Some providers already have policies that won't let me do that if
I wanted to...

You also need to prove why using global space for this is better than having
it be available for the myriad uses that *require* global space (like the
external NAT pool for all of these NAT444 and NAT64 implementations).

*As I said, the only exception that I can think of to this would be mobile
networks where they are doing significant oversubscription of their DHCP
pools (eg servicing 50M users with more like 10-15M addresses), and they
don't have the same CPE problem you're claiming prevents you from using 1918
space.

Wes George

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 12 Nov 2010 16:10:16 +1300

Wasn't it special purpose entities that brought down Enron?

The analogy is not facetious. SPEs do things that are invisible
in the architecture and they contain hidden state. Using
a non-global non-RFC1918 prefix actually introduces a new address
family that the architecture doesn't understand at all.

Do we have any idea how many bits of software and firmware
contain logic something like
   if prefix in {10/8, 172.16/12, 192.168/16} then ... ?
I presume all those components would have to be touched.

Regards
   Brian Carpenter

On 2010-11-12 15:57, james woodyatt wrote:
> On Nov 11, 2010, at 17:33, Christopher LILJENSTOLPE wrote:
> 
> Nothing like that.  More like this: the NAT444 operators incorporate a special purpose entity (SPE) for holding the assignment to one or more "shared transition" prefixes.  They obtain the prefixes the same way everyone else does, by applying to a RIR for them.  The SPE is responsible for complying with all the requirements for maintaining the allocation and keeping the routes to the prefixes clean in the default-free zone.  The NAT444 operators use the prefixes to their wicked hearts' content.  Problem solved.
> 
> 
> --

---

From: Lindqvist Kurt Erik <[email-masked]>
Date: Fri, 12 Nov 2010 05:20:28 +0100

On 11 nov 2010, at 14.00, Nick Hilliard wrote:
> Without meaning to sound overly optimistic, I would fully expect this to happen - shortly after hell freezes over.

I said could, not would. And this is the part I don't understand. I am assuming the the NAT444 implementations won't be overlaynetworks, hence existing address space is being used for...what?

Best regards,

- kurtis -

---

From: james woodyatt <[email-masked]>
Date: Thu, 11 Nov 2010 18:57:09 -0800

---

From: james woodyatt <[email-masked]>
Date: Thu, 11 Nov 2010 20:13:16 -0800

On Nov 11, 2010, at 19:10, Brian E Carpenter wrote:
> Do we have any idea how many bits of software and firmware contain logic something like
> 

Lots.  Too many to enumerate before it won't matter.  I can think of a half-dozen in my own codebase just off the top of my head.

> I presume all those components would have to be touched.

Except the proponents of this draft are motivated entirely by operational requirements for continuing to use legacy equipment.  They are explicitly not interested in upgrading anything deployed today.  They're expecting that future equipment and upgrades to existing equipment will make them IPv6-ready.

They're planning to deploy NAT444 knowing that it will break a bunch of stuff.  (I'm not sure they understand just exactly what they'll be breaking, but I doubt they care.  They have a hammer, and they're going to enjoy hammer things with it until everything is good and broken.)

---

From: Sam Silvester <[email-masked]>
Date: Fri, 12 Nov 2010 16:54:39 +1030

> A nit here, but the ask is for a /10.

I've had a read of the draft. Why a /10 (or whatever length?) - where
did this come from?

Assuming you're going to use this space for "internal devices" that
aren't capable of IPv6, it seems arbitrary.

I've heard comments that many ISPs are using many instances of RFC1918
address space for this purpose. You state the goal is to avoid clashes
with RFC1918 addressing on the customer side of the CPE - why not just
use your already allocated public space, using multiple instances and
the like to re-use a smaller block to scale to the required number of
addresses between your CPE WAN interfaces and the Big Ugly NAT Box?

Basically, it seems like a /10 might be fine for a number of carriers,
but not for others - as such it seems a hack to assign it and use a
"one size fits most" approach.

As such, I don't support this.

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Fri, 12 Nov 2010 17:42:22 +1100

James,

	I'm fine with discussion of the merits (or demerits) of the draft.  I am NOT okay with folks who have not actually been involved in the discussions, or personally know the individuals impune their motives.

> Except the proponents of this draft are motivated entirely by operational requirements for continuing to use legacy equipment.  They are explicitly not interested in upgrading anything deployed tod…

Speaking for myself, we will upgrade the gateways we can control or influence, once there are gateways that have the correct features, and it will be done over a period of time.  However, the end of that time period will NOT line up with runout.
> 
> They're planning to deploy NAT444 knowing that it will break a bunch of stuff.  (I'm not sure they understand just exactly what they'll be breaking, but I doubt they care.  

If you wish to discuss this in person, and determine if I care, I suggest we do it off list, in person, but I find this, frankly, insulting.

> They have a hammer, and they're going to enjoy hammer things with it until everything is good and broken.)

troll

---
李柯睿
Check my PGP key here:

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Fri, 12 Nov 2010 17:43:40 +1100

It's not being used for internal devices, please re-read the draft.  It is to enable NAT444 to allow the delivery of IPv4 services, after run-out, using NAT444, to act as the v4 substrate between a CPE supporting 1918 to the customer, and the public internet.

	Chris

---
李柯睿
Check my PGP key here:

---

From: David Conrad <[email-masked]>
Date: Thu, 11 Nov 2010 23:00:41 -0800

James,

On Nov 11, 2010, at 10:23 AM, james woodyatt wrote:
> But IETF doesn't have the authority to direct IANA to allocate numbers for *political* purposes.  

As far as I'm aware, IANA does not presume to evaluate IETF instructions for political content.  Simplifying a bit, if an RFC says "allocate X", IANA staff allocates X.  As far as I am aware, the proposed is no more political than the original 1918 allocations.

Regards,
-drc

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 12 Nov 2010 20:33:25 +1300

Chris,

> It's not being used for internal devices, please re-read the draft.  It is to enable NAT444 to allow the delivery of IPv4 services, after run-out, using NAT444, to act as the v4 substrate between a…

Isn't it more precisely:

"the v4 substrate between a CPE/NAT supporting 1918 to the customer, and a CGN that
connects to the public internet."

Do you have a canonical value for the maximum number of customers
that can be served by one CGN? That sets a bound on the length of prefix
you need (assuming Balkanized routing within the ISP, which I presume
is going to be SOP).

For example 100,000 customers would need a /15, re-used for each CGN.

A /10 appears to be enough for 2*22 customers per CGN, which seems
like more than plenty.

Even a /12 seems generous: 1M customers per CGN.

So my bottom line is: use 172.16/12; and a minority of customers
will have to renumber internally into 10/8.

That is IMHO much better than breaking everything that has RFC 1918
knowledge built into it.

    Brian

---

From: james woodyatt <[email-masked]>
Date: Fri, 12 Nov 2010 08:57:31 -0800

On Nov 11, 2010, at 22:42, Christopher LILJENSTOLPE wrote:

> 	I'm fine with discussion of the merits (or demerits) of the draft.  I am NOT okay with folks who have not actually been involved in the discussions, or personally know the individuals impune their motives. [...]

I don't think I've impugned anyone's motives, and it's not my intention to provoke a defensive response.  My sincere apologies, if I did.  I'll redouble my efforts to maintain a collegial tone.

I'm responding to what the authors of the draft spent over half their word count spelling out in Section 2, "Motivation."  I don't believe I've implied that their motives are dishonest, but I continue to be concerned less about what the authors are saying and much more about what the authors are leaving unsaid.

As I have said before, and I continue to maintain, the authors have not been forthcoming with either A) an accounting of what systems are known, or can be discovered in the reasonable future, to be broken under NAT444 deployments by using the non-RFC1918 private address realms the draft is intended to support, or B) a discussion of what CPE implementors are expected to do in the future with the prefix reserved by IANA from this draft.

I contend that if IETF is to take this individual submission seriously, then both of those items need to be discussed in the draft.  This is important because it isn't just operators who have limited resources for IPv6 transition engineering.  CPE implementors do too, and every person-hour of labor spent on engineering, qualifying and distributing changes to CPE software to cope with the damage operators do to IPv4 service by deploying non-RFC1918 private address realms to CPE hosts and gateways is energy that could be better spent on furthering the IPv6 transition instead.

---

From: David Conrad <[email-masked]>
Date: Fri, 12 Nov 2010 11:52:16 -0800

Chris,

Given the way the IETF "works" and based on the quantity of response this topic has generated, it would seem unlikely that a consensus can be reached before the IPv4 free pool is exhausted, regardless of the merits of the idea.  That would appear to leave folks deploying NAT444 with the option of each going to their respective RIRs and getting space (accelerating IPv4 free pool exhaustion) or everybody squatting on a hopefully allocated-but-forever-unused prefix.

With respect to the latter, I suspect the last damaging approach would be using something in 44/8. It appears _very_ sparsely populated but given its nature, it's unlikely IANA would be able to recover all of that particular block. Since IANA can't allocate anything but /8s, it is likely forever locked up... 

Regards,
-drc

---

From: Leo Vegoda <[email-masked]>
Date: Fri, 12 Nov 2010 13:40:36 -0800

On 12 Nov 2010, at 11:52, David Conrad wrote:

> Since IANA can't allocate anything but /8s, it is likely forever locked up... 

It is worth noting that this applies to the /9 and /10 left from any /10 assigned for NAT444 as well as whatever space people might be able to reclaim from a block like 44/8. That is, even if NAT444 only needs a /10, that would leave the remainder of the /8 unavailable for allocation under the current set of policies. And while people are actively working on proposals for alternate policies, that process in unlikely to be completed in the next few months.

Regards,

Leo Vegoda

---

From: Sam Silvester <[email-masked]>
Date: Sat, 13 Nov 2010 13:35:59 +1030

On Fri, Nov 12, 2010 at 5:13 PM, Christopher LILJENSTOLPE
<[email-masked]> wrote:
> It's not being used for internal devices, please re-read the draft.  It is
> to enable NAT444 to allow the delivery of IPv4 services, after run-out,
> using NAT444, to act as the v4 substrate between a CPE supporting 1918 to
> the customer, and the public internet.

I may have put that badly (Friday afternoon and all) in my original
reply - that's exactly what I meant. It seems (as has now been
commented on by a few) that a /10 seems like an awful mightly lot of
addresses to do this, considering this space would exist 'betwen' the
CPE and the CGN (I hate that term).

Can you speak as to where the decision was made for the 2^22 address
requirement & reasons why this couldn't be done with multiple
VRF-style instances of existing public IP address space?

---

From: Randy Bush <[email-masked]>
Date: Fri, 12 Nov 2010 15:57:15 +0800

> I've had a read of the draft. Why a /10 (or whatever length?) - where

they were clearly not going to get a /8

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Sat, 13 Nov 2010 06:24:07 +1100

Ok James,

> I don't think I've impugned anyone's motives, and it's not my intention to provoke a defensive response.  My sincere apologies, if I did.  I'll redouble my efforts to maintain a collegial tone.

I accept your apology.  Let's move on...

> As I have said before, and I continue to maintain, the authors have not been forthcoming with either A) an accounting of what systems are known, or can be discovered in the reasonable future, to be…

	As to your other topics, I, for one, would only deploy this space, and NAT444 against heritage CPE.  I have no intent of deploying once I have functional CPE in the field that can deal with v4 and v6 end-nodes in a v4 exhausted world (i.e. IVI, DSLite, etc).  If we had that equipment from vendors today, and it was deployed, we wouldn't be having this conversation.  Therefore, the question should be, what will the effects be on EXISTING CPE, as new CPE should not be subject to this mistreatment.

> 
> I contend that if IETF is to take this individual submission seriously, then both of those items need to be discussed in the draft.  This is important because it isn't just operators who have limited resources for IPv6 transition engineering.  CPE implementors do too, and every person-hour of labor spent on engineering, qualifying and distributing changes to CPE software to cope with the damage operators do to IPv4 service by deploying non-RFC1918 private address realms to CPE hosts and gateways is energy that could be better spent on furthering the IPv6 transition instead

	I would also point out to many folks who discussed this in the room today in regards to lengthy deployments of v6, no one has done that in a v4 exhausted world (because it hasn't happened yet).  Some service areas may have CE (Consumer electronics) and other end-nodes that are v6 capable, but I do know that that is not the case in my service area, nor in our recent hosts service area, nor in many service areas in other parts of the world.  Carriers are going to have to deal with this in SOME way with existing deployed CPE/RG until such a time as they can be replaced.  That is going to be variable as to how many RG/CPE there are, who owns them, and, certainly as important, when we actually have CPE that does the "right" thing to deploy.  Until that, we can either do something ugly, or stick our heads in the sand and pretend things aren't going to break.

	As far as the level of energy to deploy those addresses to the WAN side of CPE - that will be low compared to the energy necessary when v4 CE equipment starts failing.

Chris

---
李柯睿
Check my PGP key here:

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Sat, 13 Nov 2010 06:24:07 +1100

Ok James,

Chris

- ---
李柯睿
Check my PGP key here:

---

From: Cameron Byrne <[email-masked]>
Date: Sat, 13 Nov 2010 17:48:12 -0800

On Fri, Nov 12, 2010 at 11:24 AM, Christopher LILJENSTOLPE
<[email-masked]> wrote:
> I'm fine with discussion of the merits (or demerits) of the draft.  I am NOT
> okay with folks who have not actually been involved in the discussions, or
> personally know the individuals impune their motives. [...]
>
> I don't think I've impugned anyone's motives, and it's not my intention to
> provoke a defensive response.  My sincere apologies, if I did.  I'll
> redouble my efforts to maintain a collegial tone.
>
> I'm responding to what the authors of the draft spent over half their word
> count spelling out in Section 2, "Motivation."  I don't believe I've implied
> that their motives are dishonest, but I continue to be concerned less about
> what the authors are saying and much more about what the authors are leaving
> unsaid.
>
> As I have said before, and I continue to maintain, the authors have not been
> forthcoming with either A) an accounting of what systems are known, or can
> be discovered in the reasonable future, to be broken under NAT444
> deployments by using the non-RFC1918 private address realms the draft is
> intended to support, or B) a discussion of what CPE implementors are
> expected to do in the future with the prefix reserved by IANA from this
> draft.
>
> As to your other topics, I, for one, would only deploy this space, and
> NAT444 against heritage CPE.  I have no intent of deploying once I have
> functional CPE in the field that can deal with v4 and v6 end-nodes in a v4
> exhausted world (i.e. IVI, DSLite, etc).  If we had that equipment from
> vendors today, and it was deployed, we wouldn't be having this conversation.
>  Therefore, the question should be, what will the effects be on EXISTING
> CPE, as new CPE should not be subject to this mistreatment.
>
> I contend that if IETF is to take this individual submission seriously, then
> both of those items need to be discussed in the draft.  This is important
> because it isn't just operators who have limited resources for IPv6
> transition engineering.  CPE implementors do too, and every person-hour of
> labor spent on engineering, qualifying and distributing changes to CPE
> software to cope with the damage operators do to IPv4 service by deploying
> non-RFC1918 private address realms to CPE hosts and gateways is energy that
> could be better spent on furthering the IPv6 transition instead
>
> I would also point out to many folks who discussed this in the room today in
> regards to lengthy deployments of v6, no one has done that in a v4 exhausted
> world (because it hasn't happened yet).  Some service areas may have CE

IMHO, I would say mobile in North America looks pretty much like IPv4
exhaust already happened. All the major service providers have
compromised IP networks in some way.  They all do NAT44 today.  They
use BOGONs and overlapping address spaces, multiple instances of
RFC1918.... that's today.  There are also committed IPv6-only + NAT64
and Gi-Ds-lite deployments being deployed now.

So, there is an IPv4 exhaust model already live and "working".  It can
keep going as is, it does not get easier, but the mobile networks in
North America are not bounding their growth by available IPv4.

Cameron

> (Consumer electronics) and other end-nodes that are v6 capable, but I do
> know that that is not the case in my service area, nor in our recent hosts
> service area, nor in many service areas in other parts of the world.
>  Carriers are going to have to deal with this in SOME way with existing
> deployed CPE/RG until such a time as they can be replaced.  That is going to

Yep, nobody's getting free phones for the purpose IPv6, they just
don't get public IPv4 addresses or end to end connectivity.

> be variable as to how many RG/CPE there are, who owns them, and, certainly
> as important, when we actually have CPE that does the "right" thing to
> deploy.  Until that, we can either do something ugly, or stick our heads in
> the sand and pretend things aren't going to break.
> As far as the level of energy to deploy those addresses to the WAN side of
> CPE - that will be low compared to the energy necessary when v4 CE equipment
> starts failing.
> Chris
>
>
> --

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Mon, 15 Nov 2010 02:24:26 +1100

Greetings,

	It's a trade-off between slop in public address consumption by the CGNs and multiplication of services that need to be before the second nat (intercept comes to mind), and the desire to limit the impact of the request.

	If, say, we had a small block, and needed to re-use it 16 times, then I would need 16 intercept infrastructures, and, more importantly, 16 public address pools (one for each CGN cluster, assuming one cluster to NAT444 "network").  That means that each of the public pools will have to have buffer, vs. sharing the buffer over fewer CGN clusters.

	There is a bit of truth in what Randy says, although, not necessarily his intimation.  

1) We want to use as small a block as reasonable without causing too many problems as identified above
2) By asking for a smaller block, we hoped to remove some of the emotion and heat from the discussion.  

	Chris

---
李柯睿
Check my PGP key here:

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Mon, 15 Nov 2010 02:25:35 +1100

A reclaimed block, or contaminated block, would be fine for this exercise, btw.
	
	Chris

---
李柯睿
Check my PGP key here:

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Mon, 15 Nov 2010 02:36:15 +1100

Greetings,

	I don't think that 44/8 is reasonable (look at http://noh.ucsd.edu/~brian/amprnets.txt), or did you mean 45/8 (just recently returned)?

	Chris

---
李柯睿
Check my PGP key here:

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Mon, 15 Nov 2010 03:50:27 +1100

Greetings Michael,

On 15Nov2010, at 03.24, Michael Lambert wrote:

> On 14 Nov 2010, at 10:24, Christopher LILJENSTOLPE wrote:
> 
> If I have been reading this thread correctly, it sounds as though one of the primary drivers for this request is the inadequacy of much residential CPE.  How long is the typical replacement cycle for residential CPE (ie, how long could we expect this block to be "necessary")?

Different carriers, different scales.  It also depends if the carrier even controls the CPE/RG or if it is customer supplied.
> 
> Just to comment...  I'm sure there are residential providers that are still deploying IPv6-unfriendly gear such as DOCSIS 2.0 cable modems even though DOCSIS 3.0 has been available for several years.  I see no reason for the IETF to help mitigate operational complexities during transition for providers that are just now recognizing that IPv6 could be an "issue".

You must have missed some of the discussions in the last few days.  We've recognized it for a while, the issue is that the transition mechanisms that will keep v4 devices at home (i.e. CE, XP machines - big issue in China, for example) in an exhausted v4 world.  The vendor community is just now starting to make IVI, DSLite, etc. CPE/RG available.  Then we have to qualify, get into channels, etc.  It's just not enough time, even if the vendors had them all available now (which they don't).  Please don't assume that the authors and their companies (at least) have just "woken up" - the whole industry just took too damn long to get everything lined up for a v4 exhausted world.  

	Chris

> Michael
> Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
> 
> iEYEARECAAYFAkzgDT8ACgkQCa/+7y1tXDC2JgCePw6XLODAiVJrI9ODuXMGJQXA
> 85MAniB0qUp5nUUKeMt6cnUrLdIesPlv
> =1QzC

---
李柯睿
Check my PGP key here:

---

From: David Conrad <[email-masked]>
Date: Sun, 14 Nov 2010 08:02:07 -1000

> 	I don't think that 44/8 is reasonable (look at http://noh.ucsd.edu/~brian/amprnets.txt), or did you mean 45/8 (just recently returned)?

No, I meant 44/8.  I am aware that it is in use by a few ham operators, however I would think they given the sparseness of usage, those ham operators could renumber in other parts of 44/8, freeing up a block of sufficient size for your purposes.

Regards,
-drc

---

From: Arturo Servin <[email-masked]>
Date: Sun, 14 Nov 2010 22:38:50 -0200

> 	I don't think that 44/8 is reasonable (look at http://noh.ucsd.edu/~brian/amprnets.txt), or did you mean 45/8 (just recently returned)?

	45/8 (not all but a big chunk of it) was returned to ARIN, not to IANA.

Regards,
-as

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Mon, 15 Nov 2010 11:55:30 +1100

I know.  I was trying to clear up if he meant 45/8 or 44/8.  The problem with 44/8 is that it is in use in networks that may be connected to RG's.

	Chris

---
李柯睿
Check my PGP key here:

---

From: David Conrad <[email-masked]>
Date: Sun, 14 Nov 2010 15:48:06 -1000

On Nov 14, 2010, at 2:55 PM, Christopher LILJENSTOLPE wrote:
> I know.  I was trying to clear up if he meant 45/8 or 44/8.  

As I've indicated, I meant what I wrote (44/8).

> The problem with 44/8 is that it is in use in networks that may be connected to RG's.

RG's?

44/8 is a legacy /8 that was allocated by Jon Postel for IP over ham radio (Jon made a few assignments based on layer 2 technology, 14/8 was IP over X.25, 24/8 was IP over CATV, and 44/8 was IP over ham radio).  I believe 44/8 is currently being announced by UCSD as part of an experiment -- I don't think this was the intended use of that /8.  A small random sampling of various looking glasses appear to show three (3) more specifics being announced (specifically, 44.16.15.0/24, 44.68.52.0/24, and 44.130.99.0/24). When I was at IANA we looked at trying to recover the full /8 (like we did with 14/8) but we were informed it would be infeasible. Since current policy forbids IANA from direct allocations and handing out anything longer than a /8 to the RIRs, it was left as is. 

In any event, as I mentioned previously, regardless of the merit of what you're proposing, it seems a bit unlikely you'll get sufficient consensus to have the IETF direct IANA to reserve another block for non-unique addressing.  This leaves folks interested in NAT444 with the options of:

a) telling their customers with equipment that can't be upgraded to go out and get new CPE
b) having somebody go to one of the RIRs and get the space, then making that space NAT444 space for everybody (e.g., like what Microsoft did with 169.254.0.0/16)
c) each going out to their respective RIRs and obtaining sufficient address space to cover their NAT444 needs
d) everybody agreeing to choose an allocated but hopefully unused (for now and forever) on the Internet prefix, e.g., something that is known to be air-gapped.
e) getting a number of ham operators to dust off and renumber their KA9Q boxes (or whatever) into different prefixes in 44/8, perhaps via some sort of incentive if that's actually necessary

"Choose wisely" -- Last Knight of the First Crusade

Regards,
-drc

---

From: Michael Lambert <[email-masked]>
Date: Sun, 14 Nov 2010 11:24:22 -0500

Chris,

Michael

---

From: Richard Hartmann <[email-masked]>
Date: Mon, 15 Nov 2010 02:05:13 +0100

On Sun, Nov 14, 2010 at 19:02, David Conrad <[email-masked]> wrote:

> No, I meant 44/8.  I am aware that it is in use by a few ham operators,
> however I would think they given the sparseness of usage, those ham
> operators could renumber in other parts of 44/8, freeing up a block of
> sufficient size for your purposes.

FWIW, 44.200.0.0/13 is unused. Renumbering is not realistic, but they
have enough sparseness in the upper ranges not to need 44.200.0.0/13,
ever. I would say asking can't hurt though I am still not sure if
NAT444 is a good idea.

Richard

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Mon, 15 Nov 2010 19:43:23 +1100

That's one possible place.

	Chris

---
李柯睿
Check my PGP key here:

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Mon, 15 Nov 2010 19:46:03 +1100

>> The problem with 44/8 is that it is in use in networks that may be connected to RG's.

Residential gateways.

> a) telling their customers with equipment that can't be upgraded to go out and get new CPE

Technically great, career (and customer base) limiting - unless we ALL do it.

> b) having somebody go to one of the RIRs and get the space, then making that space NAT444 space for everybody (e.g., like what Microsoft did with 169.254.0.0/16)

Discussed already

> c) each going out to their respective RIRs and obtaining sufficient address space to cover their NAT444 needs

Wasteful

> d) everybody agreeing to choose an allocated but hopefully unused (for now and forever) on the Internet prefix, e.g., something that is known to be air-gapped.

Discussed

> e) getting a number of ham operators to dust off and renumber their KA9Q boxes (or whatever) into different prefixes in 44/8, perhaps via some sort of incentive if that's actually necessary

shifting really old networks is usually a recipe for disaster.  Would try and avois

> "Choose wisely" -- Last Knight of the First Crusade

There is no wise choice here, it's just the least stupid one.

---
李柯睿
Check my PGP key here:

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Mon, 15 Nov 2010 19:46:59 +1100

Although CPE that supports something like DSlite or IVI will allow me to re-deploy a LOT of v4.  That might reduce the need for this block over time.

	Chris

On 15Nov2010, at 19.35, Fred Baker wrote:

> 
> On Nov 15, 2010, at 12:24 AM, Michael Lambert wrote:
> 
> I would guess that once it becomes unnecessary, IPv4 will be unnecessary as well.

---
李柯睿
Check my PGP key here:

---

From: Fred Baker <[email-masked]>
Date: Mon, 15 Nov 2010 16:35:33 +0800

---

From: Richard Hartmann <[email-masked]>
Date: Mon, 15 Nov 2010 11:08:42 +0100

> There is no wise choice here, it's just the least stupid one.

You seem to have decided that getting a /10 from IANA is that least
stupid option. I am not sure that will happen before IPv4 is depleted
anyway, but that's your choice to make.

If I were you, I would start contacting people about 44.200.0.0/13 or
similar spaces.

Arguing back and forth about the relative merits of NAT444 is
pointless and I think all arguments have been exchanged. People who
think NAT444 is a good idea will not change their opinion any more.
Neither will the people who think it's a bad idea.

Richard

---

From: Mark Smith <[email-masked]>
Date: Mon, 15 Nov 2010 22:33:47 +1030

On Mon, 15 Nov 2010 02:24:26 +1100

> 	If, say, we had a small block, and needed to re-use it 16 times, then I would need 16 intercept infrastructures, and, more importantly, 16 public address pools (one for each CGN cluster, assuming…

So why should the global Internet miss out remaining IPv4 address
space, just because you want to avoid "16 intercept infrastructures"?
In your employer's market, your employer is large. On the world market,
your employer is small. Would your employer consider it fair if one of
the much larger global providers said, "we want all the available IPv4
address space for NAT444, to avoid "128 intercept infrastructures"?

I understand the specific issue of transitioning to IPv6 with customer
owned CPE. I don't however think it is fair that ISPs with this problem
to try to place opex and capex of dealing with it on the global
Internet community. These customers have participated in a market that
expects to be able to buy the CPE, from ISPs or other outlets. That
means that while they've benefited from price competition and choice,
they've also taken on some of the responsibility for the operational
costs of owning the CPE. Costs incurred due to software or hardware
upgrades, or costs incurred by their ISP dealing with them not
performing software or hardware upgrades when necessary, should be
borne by the people who've created and benefited from that market form
- the customers. As an ISP, that means passing on those increased capex
and opex costs onto to the customers themselves, not the global
Internet community.

---

From: Roger Jørgensen <[email-masked]>
Date: Mon, 15 Nov 2010 13:46:38 +0100

On Mon, Nov 15, 2010 at 2:48 AM, David Conrad <[email-masked]> wrote:
<snip>

> "Choose wisely" -- Last Knight of the First Crusade

Don't sound like there are any good, just bad choices to make.

For those that "need" NAT444, random(a-e) and go with it. It will very likely
cause problem no matter what you do.
I'm so naive I belive it will be better to focus 100% on do the IPv6 change
and let IPv4 die :)

-- 

Roger Jorgensen           |

---

From: David Conrad <[email-masked]>
Date: Mon, 15 Nov 2010 13:38:46 -1000

On Nov 15, 2010, at 1:16 PM, Michael Newbery wrote:
> NAT444 doesn't solve their looming next problem---that of being unable to access the (rapidly) increasing IPv6-only Internet, and absent working NAT46 and with no likely prospect of same, the ONLY way they will get this access is by upgrading their CPE.

> 
> Am I missing something obvious?

When do you expect there to be any commercially viable sites or services that are reachable via IPv6 only?

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Mon, 15 Nov 2010 14:02:39 -1000

Martin,

On Nov 15, 2010, at 1:57 PM, Martin Millnert wrote:
> Either your question or my interpretation of it seems to be malformed,
> because I see several commercially viable (or so one would assume, at
> least by appearance) websites reachable via IPv6-only:

Sorry if I was unclear -- the implication of "via IPv6 only" is that you can't also reach it via IPv4.

The point I was trying to make is that I suspect that any commercial site or service that intends on becoming or staying viable is going to have to provide access via IPv4 for the foreseeable future.  The installed base of IPv4-only is simply too large to do otherwise.

Regards,
-drc

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 16 Nov 2010 08:32:04 +0800

Joel's widget number 2

On Nov 16, 2010, at 7:48, Michael Newbery <[email-masked]> wrote:

> 
> On 16/11/2010, at 12:38 PM, David Conrad wrote:
> 
> It's not just the 'hosts'. A large amount of traffic is peer to peer, and I don't mean file sharing. If you only have an IPv4 address and want to game, or VoIP to someone with only an IPv6 address, then you are going to be upset.

Hosts running IP stacks are both clients and servers. So long as IP has existed that has been the case. P2P applications are the natural state of things rather than some odd corner case.

It's fair to conclude that whatever happens, the p2p case in the v4 space is going to continue to erode and if you want to preserve your ability to do that, you're going to have take positive steps to retain it.

---

From: james woodyatt <[email-masked]>
Date: Mon, 15 Nov 2010 17:12:16 -0800

> When do you expect there to be any commercially viable sites or services that are reachable via IPv6 only?

The services reachable using the Back To My Mac™ feature of Mac OS X, which was introduced in October 2007 are all IPv6-only.  Granted, the IPv6 network in question is addressed with RFC 4193 Unique Local Addresses overlaying the public IPv4 Internet using an IPsec-over-UDP overlay.  The default-free zone is not involved.  Nevertheless, Back To My Mac™ is part of a commercially viable service, and it's IPv6-only.

I mention this to expose an important flaw in the premises of the question.  One thing you very quickly learn about building any kind of network: utilization always follows capacity.  If you're expecting to find the next wave of IPv6-only sites and services to be hosted in the massive data centers where the current IPv4-only content lives, then you're probably going to be waiting a long time before you see it.  The capacity isn't being added there.

If, on the other hand, you're looking for it to appear first on dual-stack subscriber networks that only reachable from the public Internet over IPv6 (modulo policy), then you're probably looking in the right place for it.  That's where the new capacity will be appearing soon.  After that, the utilization of the capacity will follow.

---

From: Michael Newbery <[email-masked]>
Date: Tue, 16 Nov 2010 12:16:22 +1300

> Technically great, career (and customer base) limiting - unless we ALL do it.

But, is it not a fair assumption that nearly all customers with equipment that can't be upgraded already have an IPv4 address?

If someone comes to me with a Windows ME machine and asks for a new connection, then I'm not going to feel guilty in gently telling them they need a new machine. Jesting aside, if someone comes to me with new CPE that doesn't do IPv6 and asks for a new connection, then I will politely decline and point out that they need equipment that is fit for purpose.

We are running out of IPv4 addresses because of growth, because of new customers, with new equipment.

That leaves:
* customers stuck with IPv4 because the ISP can't do IPv6 in their access network and
* customers with old equipment transferring from another ISP.

---

From: Michael Newbery <[email-masked]>
Date: Tue, 16 Nov 2010 12:48:29 +1300

---

From: Martin Millnert <[email-masked]>
Date: Tue, 16 Nov 2010 00:57:33 +0100

anticimex@natalie:~$ dig google.com aaaa +short
2a00:1450:8001::93
anticimex@natalie:~$ dig www.v6.facebook.com aaaa +short
2620:0:1cfe:face:b00c::3

Now add NAT64, and the web should work increasingly fine for an
increasing amount of sites from a host with IPv6-only.

Additionally, there are rumors of CDN(s) becoming IPv6-capable *very*
soon.

Cheers,
-- 
Martin Millnert <[email-masked]>

---

From: Martin Millnert <[email-masked]>
Date: Tue, 16 Nov 2010 01:29:34 +0100

On Mon, 2010-11-15 at 14:02 -1000, David Conrad wrote:
> The point I was trying to make is that I suspect that any commercial
> site or service that intends on becoming or staying viable is going to
> have to provide access via IPv4 for the foreseeable future.  The
> installed base of IPv4-only is simply too large to do otherwise.

Ah, sure (my bad I guess).  Michaels point still stands though. For the
record:

The globally unique IPv4 and IPv6 Internets can *in theory* overlap
today, if you ignore all hosts behind v4-NATs.

This theoretical overlap will soon *definitely* be over.

Each consecutive day following the tipping point, the two Internets can
only grow more and more distinct, and even more so as the previously
non-fully-participating Internet hosts, hidden behind v4-NATs (even
v4-NATs of the future, used to reach non-transitioned content servers),
joins the future v6-Internet.  That is, the eventual "liberation" of
many v4-NAT:ed hosts will make for a much more addressable Internet.

Internet will live and die by this happening. A strict eyeball/content
divided Internet is to me nothing more than a very far-reaching
broadcast network of the more classical 20th century designs, and I
think this is very unlikely to happen.

Instead, I'm content the transition will happen, even "by itself" (the
market), and I look forward to the media hype of January-May next year.
There are a few things that can be done to make the transition go
faster/more smoothly though, even without regulation. First on that list
is more content available from a IPv6-only host, something that is
improving on a daily basis already. Once large content providers agree
that serving content on general IPv6 is OK, we'll have come a long way!

Cheers,

---

From: Randy Bush <[email-masked]>
Date: Tue, 16 Nov 2010 07:14:54 +0100

> But, is it not a fair assumption that nearly all customers with
> equipment that can't be upgraded already have an IPv4 address?

it is not that they *can't* be upgraded.  it's just that the provider
wants us all to pay the cost for them not upgrading cpe and not having
pushed the v6 issue with their cpe years ago.  and we are being asked to
pretend it is positive, and to pay for the damage, thet they are trying
to hold on to bastardized ipv44444 for more years.

randy

---

From: Roger Jørgensen <[email-masked]>
Date: Tue, 16 Nov 2010 07:42:04 +0100

On Tue, Nov 16, 2010 at 12:16 AM, Michael Newbery <[email-masked]> wrote:
<snip>
> NAT444 doesn't solve their looming next problem---that of being unable to
> access the (rapidly) increasing IPv6-only Internet, and absent working NAT46
> and with no likely prospect of same, the ONLY way they will get this access
> is by upgrading their CPE.

No not really.

I guess from a business point of view some will probably feel its
suicide to not
bow to every (unreasonable) demand from their customers. From a economical
point of view it might be true. But just partly I believe.

Give the customers a clear choice, again scary for some, either you can keep
your old equipment and not being able to use every new service popping up,
not able to reach everything etc. Or you can just get this new product, cost
the same every month, have to pay XXX for new equipment and you're set
to go for the future.

I as a customer would love to have an ISP giving me that choice. Of course,
I might be a bit more technical than the average joe that only want thing
to work whenever its turn on.

... but in the end, I belive it is not a technical problem. It is more
a decision
making (or not making) problem.

-- 

Roger Jorgensen           |

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 16 Nov 2010 07:52:48 +0100 (CET)

On Sun, 14 Nov 2010, David Conrad wrote:

> b) having somebody go to one of the RIRs and get the space, then making 
> that space NAT444 space for everybody (e.g., like what Microsoft did 
> with 169.254.0.0/16)

Isn't 169.254.0.0/16 an excellent network to use for NAT444 ? I agree that 
it's not that huge, but it's still 64k addresses, one would have to make 
sure the CGN can handle interface context (multiple instances of the same 
space) and then one would be good to go. It's there, using LL between CPE 
and ISP actually sounds perfect, that's what I want to do for IPv6 as well

:P

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Erik Kline <[email-masked]>
Date: Tue, 16 Nov 2010 16:05:13 +0900

On 16 November 2010 15:52, Mikael Abrahamsson <[email-masked]> wrote:
>> that space NAT444 space for everybody (e.g., like what Microsoft did with
>> 169.254.0.0/16)
>

+1  Or 198.18.0.0/15?  =)

But I would guess that supporters of this NAT444 stuff have already
picked over the things that http://tools.ietf.org/html/rfc5735 has to
offer.

---

From: Sam Silvester <[email-masked]>
Date: Wed, 17 Nov 2010 09:05:52 +1030

On Mon, Nov 15, 2010 at 1:54 AM, Christopher LILJENSTOLPE
<[email-masked]> wrote:
> Greetings,
> It's a trade-off between slop in public address consumption by the CGNs and
> multiplication of services that need to be before the second nat (intercept
> comes to mind), and the desire to limit the impact of the request.
> If, say, we had a small block, and needed to re-use it 16 times, then I
> would need 16 intercept infrastructures, and, more importantly, 16 public
> address pools (one for each CGN cluster, assuming one cluster to NAT444
> "network").  That means that each of the public pools will have to have
> buffer, vs. sharing the buffer over fewer CGN clusters.

I get that, but still, you are talking around 4.2 million addresses if
my math doesn't fail me. How many really do you plan on sitting on the
one CGN box/cluster?

It does sound to me a little like you are trying to minimise your own
costs & inconvenience by requesting an overly large range, which I'm
doubtful actually counts as justification.

> problems as identified above

Sounds more like you want to use as large a block as possible to
minimise the infrastructure duplication based on the above.

> heat from the discussion.

Fly under the rader, so to speak? I dunno if that possibly looks
worse, being sneaky and all. If the idea is sound, then the
justification should follow for an appropriately sized allocation. /8
sounds "too big" to me, so does a /10.

Sam

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Wed, 17 Nov 2010 12:05:59 +1100

> picked over the things that http://tools.ietf.org/html/rfc5735 has to
Yes, we have :)

---
李柯睿
Check my PGP key here:

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Wed, 17 Nov 2010 12:32:26 +1100

Ok folks,

	It is obvious that the operations area can not reach consensus on an operator driven request.  Continued dDOS on this list, and on the respondents time, so I suggest we put this conversation to bed.  If we can assemble the data in time (based on the agreement from Friday afternoon), we will bring it back up.  Else, the authors, and others, will (I assume) pursue one or more other courses of action.

	I would like to thank those that had reasoned arguments, and responded civilly, and actually listened to the operational issues being raised - even if we didn't agree, those were reasonable discussions, and appreciated.  Most, if not all, of those inputs will be incorporated into whatever is done next.

	To those of you who sniped, made assumptions about underlying motivations, and the authors' desire (or not) to get this v6 pig in the air in a v4 exhausted world, etc. your comments were at least entertaining (mostly).  How much they actually contributed to the body of the conversation, other than to raise the temperature, I'm not sure, nor do I really care.

	I would leave this conversation with one final observation.  The operators are at fault here, but guess what, so are the rest of us.  We spent WAY too much time discussing the PERFECT transition mechanism, rather than a suite of WORKABLE transition mechanisms to deal with runout (which is different than a clean dual-stack world).  I believe we now have them, but they are new, and will get to the market (in the form of code, CPE, etc) too late to make this a clean transition.  There will be consequences, and it will be ugly until we can get to a clean transition state.   

	Operators didn't push for transition CPE because of tactical requirements, vendors didn't develop or ship for the same reason, and the CE vendors don't see anything to plug into.  We will now all live with the consequences for a while.  It's just going to be a choice as to which consequences you choose (or are chosen for you).

	I am neither speaking for the other authors here, nor my current, nor previous employers
	
	Chris

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 17 Nov 2010 21:28:20 -0800

On 11/17/10 3:48 PM, Antonio Querubin wrote:
>> I believe 44/8 is currently being announced by UCSD as part of an
>> experiment -- I don't think this was the intended use of that /8.  A
> 
> Is experimentation now an illegitimate reason for keeping an allocation?
> 
>> that is known to be air-gapped. e) getting a number of ham operators
>> to dust off and renumber their KA9Q boxes (or whatever) into different
>> prefixes in 44/8, perhaps via some sort of incentive if that's
>> actually necessary
> 
> Too little too late.  Probably just as easy (or difficult) to convince
> ham operators to migrate to IPv6.

ham operators are know to be rather flexible (I'd expect most of the
one's using ip based digital repeaters to be capable of reconfiguring
their home cpe for example). While I'm moderately familiar with some
applications of 44/8 in the ham space, I can also imagine them adopting
a 6lowpan suite of technologies as better suited to that application
over the long term.

> Antonio Querubin
> 808-545-5282 x3003
> e-mail/xmpp:  [email-masked]

---

From: Antonio Querubin <[email-masked]>
Date: Wed, 17 Nov 2010 13:31:21 -1000 (HST)

On Fri, 12 Nov 2010, David Conrad wrote:

> With respect to the latter, I suspect the last damaging approach would 
> be using something in 44/8. It appears _very_ sparsely populated but 
> given its nature, it's unlikely IANA would be able to recover all of 
> that particular block. Since IANA can't allocate anything but /8s, it is 
> likely forever locked up...

I wouldn't characterize it as unused.  It may be sparsely populated but 
the geographic and organizational dispersion of the 44/8 assignees I think 
makes it very impractical to try to recover reusable portions of it in a 
reasonable amount of time.

Antonio Querubin
808-545-5282 x3003

---

From: Antonio Querubin <[email-masked]>
Date: Wed, 17 Nov 2010 13:48:23 -1000 (HST)

> that is known to be air-gapped. e) getting a number of ham operators to 
> dust off and renumber their KA9Q boxes (or whatever) into different 
> prefixes in 44/8, perhaps via some sort of incentive if that's actually 
> necessary

Too little too late.  Probably just as easy (or difficult) to convince ham 
operators to migrate to IPv6.

Antonio Querubin
808-545-5282 x3003