j: Next unread message
k: Previous unread message
j a: Jump to all threads
j l: Jump to MailingList overview
- 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
- 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.