Subject: [OPSAWG] Second Draft update and more input requested for draft-azinger-additional-private-ipv4-space-issues

From: "Azinger, Marla" <[email-masked]>
Date: Tue, 2 Feb 2010 13:47:56 -0500

Hi,

We have updated draft-azinger-additional-private-ipv4-space-issues-02 following the very helpful comments we received both on and off-list. In order to get more feedback we are going to solicit feedback from INTAREA and V6OPS in addition to OPSAWG where we have submitted the document.

The changes made on this updated version are summarized below:

1. The abstract has extra text explaining the purpose of the document

2. The section numbering has been changed in-line with Alfred's suggestion

3. The number of unallocated /8s has been updated

4. A reference to the NRO's RIR Policy Comparison Matrix section on transfers has been added in 4.3

5. A reference to draft-davies-reusable-ipv4-address-block has been added in 4.1 and 5.15.

6. Transfer policy work has been attributed to the RIR communities in 4.3, as per Ricardo's note

7. A typo ("of of" to "use of") has been corrected in the 2nd paragraph of 5.1

8. A reference to the IPv4 report page has been added as per Alfred's suggestion

9. We have added extra text on selecting a prefix length for new private space in 5.1

10. We have added extra text on people using parts of the "used" /8s for private space in 5.1

11. We have noted that 1.0.0.0/8 was allocated in January 2010

12. The non RFC and I-D references are now ordered alphabetically

The draft can be found at:

http://tools.ietf.org/html/draft-azinger-additional-private-ipv4-space-issues-02

and there's a diff highlighting the changes:

http://tools.ietf.org/rfcdiff?url2=draft-azinger-additional-private-ipv4-space-issues-02.txt

Kind regards,

Marla Azinger & Leo Vegoda

---

From: Ricardo Patara <[email-masked]>
Date: Wed, 3 Feb 2010 10:46:36 -0200

Hi Marla,

I have just read the document, and appreciate the changes.
But still have some comments :)

On 5.1, it is written:

"... However, this benefit incurs a cost by reducing the pool of global unicast
   addresses available to end users."

I would say that the those addresses would be available to any "organization", including ISPs. And not only "end users" The wording "end user" might have a special meaning in the RIR context, indicating those organizations that do not provide Internet access to third parties but need their dedicated set of IPs.

Regarding the objectives of the document. I liked the added part of the abstract, but still does not understand it, specially considering the point 5.3.
It kind of leaves a message that some action needs to be taken, because the problem is out there and will have a strong impact on the free space.

Still, I think mention should be make to policies already implemented in various RIRs regarding how to deal with the last /8 (basically, making hard for an ISP to get a big chunk of addresses)

Thanks and regards
Ricardo Patara
--

Em 02/02/2010, às 16:47, Azinger, Marla escreveu:

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

---

From: Leo Vegoda <[email-masked]>
Date: Thu, 4 Feb 2010 16:21:02 -0800

Hi Ricardo,

On 3 Feb 2010, at 4:46, Ricardo Patara wrote:

[...]

> I would say that the those addresses would be available to any "organization", including ISPs. And not only "end users" The wording "end user" might have a special meaning in the RIR context, indic…

In a general context "end user" can include ISP customers, ISP infrastructure and non-Internet IP networks. If the term could be misunderstood by one group of users, though, something else might be appropriate. What would you suggest?

> It kind of leaves a message that some action needs to be taken, because the problem is out there and will have a strong impact on the free space.

We believe this document displays the fact that there are pros and cons to the various issues and it doesn't allude to or make claim to a solution statement in either direction.  We believe it is important to document the available options and their consequences. If we do this well and then it becomes clear that no action or an action or of some kind should be taken, then we will be on sound ground when making that decision.

> Still, I think mention should be make to policies already implemented in various RIRs regarding how to deal with the last /8 (basically, making hard for an ISP to get a big chunk of addresses)

That is clearly another important factor. Thank you for raising it. This probably fits quite well into 5.3. What do you think?

Thanks,

Leo & Marla

---

From: "Davies, Greg J" <[email-masked]>
Date: Mon, 8 Feb 2010 12:20:38 +1100

Hi Marla and Leo,
 
The following are some comments on the second draft for your consideration:

* Section 3 first paragraph - At the moment this paragraph sounds too definitive in saying that peer to peer communication won't work through NAT and therefore require a globally unique address.  In practice most of the popular peer to peer applications (e.g. P2P file sharing clients, VoIP clients, etc.) will work through NAT because they use NAT traversal techniques.  I believe a brief reference to 'NAT Traversal' should be incorporated into this paragraph.

* Section 3 second paragraph - This paragraph says there is a tendency for low-cost CPE to use 192.168.0.0/16 as the default allowing providers to make full use of 10.0.0.0/8.  In Australia at least it appears that low-cost CPE is just as likely, if not more likely, to use 10.0.0.0/24 or 10.0.1.0/24 (or in extreme cases it could even be 10.0.0.0/8)as the default LAN address range. This makes it more difficult for the provider to choose a non-conflicting range.

* Section 5.1 first paragraph - Where you say "this benefit incurs a cost by reducing the pool of gobal unicast addresses" perhaps this could be qualified a bit more.  For example, reducing the pool by a /8 would bring forward the global run-out by about one month.  Whether the run-out is one month or the next is not such a big cost if the benefit is a working solution that mutiple providers can use for the entire transition period. The cost may therefore be acceptable.
  
Regards,
Greg  

Greg Davies 

Emerging Network Technology and Architecture 
Chief Technology Office 
Telstra Corporation Limited 

Phone   +61 3 9634 3640 
Mobile  +61 419 597 497 
Email   [email-masked] 

The information contained in this e-mail is confidential. It is only intended for the recipient/s named above. If you are not the intended or one of the intended recipient/s
any unauthorised use is prohibited. If you have received this e-mail in error, please notify the sender so that arrangements can be made for its retrieval or destruction.
Telstra Corporation Limited ACN 051 775 556 

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of Azinger, Marla
Sent: Wednesday, 3 February 2010 5:48 AM
To: [email-masked]
Subject: [OPSAWG] Second Draft update and more input requested for draft-azinger-additional-private-ipv4-space-issues

Hi,

http://tools.ietf.org/html/draft-azinger-additional-private-ipv4-space-issues-02 <http://tools.ietf.org/html/draft-azinger-additional-private-ipv4-space-issues-02> 

http://tools.ietf.org/rfcdiff?url2=draft-azinger-additional-private-ipv4-space-issues-02.txt <http://tools.ietf.org/rfcdiff?url2=draft-azinger-additional-private-ipv4-space-issues-02.txt> 

Kind regards,

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 08 Feb 2010 15:07:22 +1300

> * Section 3 second paragraph - This paragraph says there is a tendency for low-cost CPE to use 192.168.0.0/16 as the default allowing providers to make full use of 10.0.0.0/8.  In Australia at leas…

There are also CPE using parts of 1/8, which has just been released
for use by APNIC and will definitely cause trouble. Not sure if
that helps or hinders the draft, but it does illustrate the dangers
of assuming *anything* about CPE.

    Brian

---

From: Ricardo Patara <[email-masked]>
Date: Mon, 8 Feb 2010 14:38:28 -0200

Hi Leo,

> In a general context "end user" can include ISP customers, ISP infrastructure and non-Internet IP networks. If the term could be misunderstood by one group of users, though, something else might be…

I understand your point. But, maybe using another wordering might be better. Maybe something in the line of:

"... However, this benefit incurs a cost by reducing the pool of global unicast
 addresses available to organizations and users in general."

> We believe this document displays the fact that there are pros and cons to the various issues and it doesn't allude to or make claim to a solution statement in either direction.  We believe it is i…

Understood, it is clear now. But, in this case, 5.3 only says that one potential risk would having those ISPs requesting big blocks to the RIR. This is mentioned as one of the available options (4.1).
I think there might other "risks", which were also indicated on the chapter 4. Like using unallocated IPv4 address space, for instance.

What I am saying is that, only one risk is being highlighted in case of not creating a new reserved space, and it is not clear for me why is that.

> That is clearly another important factor. Thank you for raising it. This probably fits quite well into 5.3. What do you think?

I agree

thanks,
Ricardo