APNIC Home APNIC Home
Info & FAQ |  Resource services |  Training |  Meetings |  Membership |  Documents |  Whois & Search |  Internet community

You're here:  Home  Mailing Lists sig-policy 


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sig-policy] prop-058-v001: Proposal to create IPv4 shared use address space, among LIRs




2.  Summary of current problem
------------------------------

LIRs providing firewall and IP connectivity services behind NATs using
RFC 1918 address space face potential address space collisions between
end user networks that are using the same RFC 1918 address ranges.

This is stated as the problem. How does a shared use address pool solve this problem??

RFC1918 collides, because everyone can use it.

The authors' proposed /8 will also collide, because everyone will then use it.

So this proposal does not solve the above problem.

This is preventing LIRs and their end users from benefitting from the
security and efficient IPv4 address use that firewalls and NATs can
provide.

NATs do not provide security.

Instead, some LIRs are applying (and receiving) global IPv4 address
allocations to providing firewall and IP connectivity services.

Which APNIC policy dictates that LIRs *must* use global IPv4 addresses behind NATs? There isn't one I'm aware of, so this is an LIR created problem. Why do we need to fix APNIC policies because LIRs are "not using IPv4 addresses properly"?

Furthermore, if LIRs assign only IPv6 addresses to end users, they
cannot communicate with non-IPv6 ready site.

Are there any IPv6 only sites now? Their folly for discarding IPv4, real or NAT'ed. Not an APNIC policy problem.

By having IPv4 shared use address space as an alternative to RFC 1918
address ranges, LIRs would not need to request global IPv4 allocations
to achieve their aims. Therefore LIRs can continue to provide IP
connectivity after IPv4 free pool exhaustion.

This proposal simply desires to extend RFC1918 address space. The previous effort to do this a few years back was thrown out. Different authors, same proposal, wasting APNIC Policy meeting time yet again.

On 3 August 2007, the following Internet Draft was submitted to the
IETF:

     - Redesignation of 240/4 from "Future Use" to "Limited Use for
       Large Private Internets"
       http://www.ietf.org/internet-drafts/draft-wilson-class-e-01.txt

What has this got to do with the proposal? Nothing. And it is pretty much accepted that use of the 240/4 address block as an RFC1918 extension is a non-starter due to the massive deployed infrastructure that simply cannot handle it.

4.2. Conditions for use of this shared use address space are:

     - All LIRs in the AP region can use the address space

     - LIRs can choose a range within the shared space for their use
       without needing to apply to APNIC or NIRs

     - LIRs do not need to register use of their chosen shared use
       range

     - Global/regional address uniqueness is not guaranteed

     - End-users cannot use this proposed address space and should
       continue to use the existing RFC 1918 address ranges.

     - LIRs are free to assign this shared use addresses to their
       customers.

     - Use of shared use address space will not be included when
       calculating APNIC fees

Yes, all like RFC1918 space. Wouldn't it have been more polite to ask Tony Hain to resubmit his previous proposal?

5.   Advantages and disadvantages of the proposal
-------------------------------------------------

Advantages:

     - It promotes effective use of global IPv4 address space, as the
       largest LIRs will use this proposed address space rather than
       global addresses

It will still have to be NATed though, so I don't see how this can be a claimed advantage.

     - By using this shared use address space, LIRs can continue to
       provide IPv4 connectivity even after the IPv4 address exhaustion

They can also do so with routable address space.

     - LIRs can provide IPv4 connectivity by dual-stacking shared use
       addresses with IPv6 addresses. This is important as we currently
       do not have high-throughput IPv6-IPv4 translators for commercial
       use

Has anyone got IPv6 traffic that and IPv6 to IPv4 translator can't handle? Extending RFC1918 address space doesn't solve the IPv6 transition problem.

This proposal needs to sort out what problem it is trying to solve. In this state, it does little more than waste conference time.

philip
--