ietf
[Top] [All Lists]

Re: Consensus Call: draft-weil-shared-transition-space-request

2011-11-28 17:08:04
In my opinion, having a designated space is better than "squat" space, given 
that we we already know that squat space is being used. The argument that it 
extends the life of IPv4 is, IMHO, of limited value; yes, it allows operators 
to keep their IPv4 service running; given the number of CPE Routers that lack 
IPv6 capabilities, that will likely be necessary for the equipment lifetime of 
a CPE Router barring extraordinary activities on the part of vendors and 
operators to replace the current load of CPE Routers in favor of IPv6-capable 
upgrades.

IMHO, the space should be allocated.

On Nov 28, 2011, at 1:25 PM, Ronald Bonica wrote:

On October 10, 2011, the IESG issued a last call for comments regarding 
draft-weil-shared-transition-space-request-09 (IANA Reserved IPv4 Prefix for 
Shared CGN Space). While the community did not display consensus supporting 
the draft, it also did not display consensus against the draft. Therefore, I 
will submit the draft to the full IESG for its consideration at its December 
1 teleconference. The draft will be published as a BCP if a sufficient number 
of IESG members ballot "Yes" or "No Objection", and if no IESG member ballots 
"Discuss".

Because the decision to submit this draft to the full IESG is controversial, 
I will explain the decision making process.

The IETF has a precedent for interpreting silence as consent. Typically, if a 
last call elicits no response, the draft is brought to the full IESG for 
consideration. The October 10 last call regarding 
draft-weil-shared-transition-space-request-09 evoked only two responses. One 
response supported publication of the draft while the other was opposed to 
it. The respondent voicing support for the draft offered no rationale. The 
respondent objecting offered many editorial comments, but almost no rationale 
for blocking the draft once the editorial comments are addressed.

Because the October 10 last call elicited so little response, and because 
many community members have privately expressed strong opinions regarding 
this draft, I will summarize outstanding issues below. The following are 
arguments *against* draft-weil-shared-transition-space-request:

- Allocation of a special-use /10 does not hasten the deployment of IPv6. It 
only extends the life of the IPv4 network.
- If a special-use /10 is allocated, it will be used as additional RFC 1918 
address space, despite a specific prohibition against such use stated by the 
draft.
- If a special-use /10 is allocated, it will encourage others to request 
still more special-use address space.
- Some applications will break. These applications share the characteristic 
of assuming that an interface is globally reachable if it is numbered by an 
non-RFC 1918 address. To date, the only application that has been identified 
as breaking is 6to4, but others may be identified in the future.

Arguments *supporting* draft-weil-shared-transition-space-request-09 assume 
that operators will deploy CGNs and will number the interfaces between CGN 
and CPE. If the /10 proposed by draft-weil-shared-transition-space-request is 
not allocated, operators will number from one of the following:

- public address space 
- RFC 1918 address space
- squat space

If operators number from public address space, they will deplete an already 
scarce resource. If operators number from RFC 1918 space and the same RFC 
1918 space is used on the customer premise, some CPE will behave badly. The 
consequences of numbering from squat space are determined by the squat space 
that is chosen.

In summary, allocation of the /10 will have certain adverse effects upon the 
community. However, failure to allocate the /10 will have different adverse 
effects on the community. The IESG is being asked to choose the lesser of two 
evils.


--------------------------
Ron Bonica
vcard:       www.bonica.org/ron/ronbonica.vcf

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf