At 09:16 10-10-2011, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'IANA Reserved IPv4 Prefix for Shared CGN Space'
<draft-weil-shared-transition-space-request-09.txt> as a BCP
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@xxxxxxxx mailing lists by 2011-11-07. Exceptionally, comments may be
In November 1988, the following question was asked:
"Has anybody made any serious estimates of how long it will be
before we run out of 32-bit IP addresses?"
From Section 3:
"Service Providers MUST NOT number the interfaces in question from
usurped globally unique address space (i.e., squat space).
The above requirement has nothing to do with this proposal. Writing
"Thou shalt not steal" in a BCP [1] won't make it happen.
From Section 4:
"Service Providers MUST filter incoming advertisements regarding
Shared CGN Space. One exception to the above proscription against
exchanging routes for Shared CGN Space is in the case of a defined business
relationship between two Service Providers (e.g., for hosted CGN
service)."
I suggest dropping the "defined business relationship" as the ability
to make money is not worthy of a technical discussion. As there is
an exception to the requirement, it could be turned into a SHOULD.
"Reverse DNS queries for Shared CGN Space addresses MUST NOT be
forwarded to the global DNS infrastructure."
It is improbable that reverse DNS queries will not be forwarded to
the global DNS infrastructure. For what it's worth AS112 is not an
IETF project.
In Section 5.1:
"Some existing applications discover the outside address of their
local CPE, determine whether the address is reserved for special-use,
and behave differently based on that determination."
"Outside" could be replaced with "Internet-facing".
"While the assumption that a non-special-use address is reachable from
the global Internet is generally safe, it is not always true (e.g.,
when the CPE outside interface is numbered from globally unique
address space but that address is not advertised to the global
Internet as when it is behind a CGN). Such an assumption could cause
certain applications to behave incorrectly in those cases."
A global network can be described as "an address realm with unique
network addresses". The assumption that such networks (see 11/8 or
25/8) are reachable from the global Internet is a stretch too far.
Section 5.2 contains a discussion of 6to4 and how to mitigate turning
it into history. It's not worth the effort to save 6to4.
Could the "similar business relationship" be removed from Section
6? It is not the business of the IETF to discuss about business
relationships in RFCs.
This draft is an improvement compared to the version that was
previously Last-Called. I unfortunately cannot support its
publication. The IPv4 assignment is neither an assignment for
private networks nor is it for public networks. It can only serve to
break applications.
As mentioned in RFC 6264, "deployment of NAT444 CGN allows ISPs to
delay the transition and therefore causes double transition costs
(once to add CGN and again to support IPv6)". There are some other
technologies, such as port slicing [2], that have been proposed to
delay the demise of IPv4 addresses.
It would be inconsiderate of me not to propose a means to resolve a
Last Call objection. I can only think of an economic
motivation. The budget of the ITU is currently CHF 322
million. ICANN has a budget of USD 67 million. ARIN has a revenue
of USD 14 million. RIPE NCC has a total income of EUR 17 million.
APNIC has a revenue of AUD 13 million. The budgets of LACNIC and
AfriNIC are around USD 2 million each. IETF revenue is around USD 3
million with USD 2 million funded through attendance fees. It would
be inappropriate [3] to ask the ITU or ICANN for money. The RIRs,
however, could consider making an annual donation of USD 823000 to
the IETF as a gesture of goodwill for this IPv4 address
assignment. I suggest adding text to this draft about that. :-) The
donation would be used to halve the IETF attendance fee.
Regards,
-sm
1. http://www.ripe.net/ripe/mail/archives/routing-wg/2011-October/001972.html
2. Why allow 65335 ports for an end user when a thousand ports is
more than enough for each end user? :-)
3. The argument is left as an exercise to the reader.
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf