- 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?
- 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
--
