IANA-Reserved IPv4 Prefix for Shared Address Space
draft-weil-shared-transition-space-request-15

[Ballot comment]
My thinking has evolved through the last call discussions.  I now
have no objection to publishing this document.

In my original Discuss, I raised a few questions ... here are my
answers to those questions:

  Is the IESG the appropriate body to make the decision?  If no, where
  should the decision be made, perhaps with technical advice from the
  IETF?

Yes.  The IETF should make the decision about ARIN's assignment
of the requested address block.

  Should the IESG identify any specific /10 for use as Shared CGN
  Space?  If no, do not approve the document.

Yes, identification of a specific /10 will avoid squatting or multiple
assignments of address blocks to individual service providers.

  Does this document describe the usage scenarios, constraints and
  caveats sufficiently well to allow the use of a /10 as Shared CGN
  Space?  If no, ask for a revision.

The text describing the usage of this /10 has evolved through the
various discussions and there appears to be consensus for the
current text.

  Should the IESG approve a request to IANA for a /10 as described
  in the document?  If yes, publish the document.

There appears to be rough consensus for approval at this point in time.

  Should the IESG request that IANA identify some other /10 (or
  similar address block), such as 172.16.0.0/12, 10.64.0.0/10 or
  240.0.0.0/10 for use as Shared CGN Space?

Yes.

One last point has been discussed: whether this address block
assignment is appropriate because it will be used only for
extending the lifetime of IPv4.  My opinion now is that this
consideration is a non-issue.  We need to do something to
keep the Internet running today.  IPv6 is the long-term
solution, regardless of what bandaids service providers choose
to spend money on today.

[Ballot comment]
Based on more and more and more and more discussion I'm reluctantly
ok with this. (Still)


In December I said:

  I think additionally allocating part of 240/4 would be a fine thing to do at
  the same time within the same document. I would not be that keen on
  punting on the 240/4 part allocation until later since that would engender
  most of the same discussion.

I still think that'd be good but it doesn't seem to have gotten traction
so I'm in the end also ok to go ahead without that.

[Ballot discuss]
I understand the commercial imperatives that the ISPs face, and appreciate this is a dilemma.

However, the authors have not so far generated an adequate degree of consensus (as evidenced by discussions on the IETF list) that the deployment of this technology "makes the Internet work better". Indeed section 5 indicates that the deployment of this technology makes the Internet worse by reducing it to a network that only supports a limited range of services (Web, Mail and IM) sanctioned by the ISP. This seems contra to the mission of the IETF.

If this were a clearly defined limited application network, a case could be developed for accepting restrictions, but the application described here is connectivity to the Internet and hence access to new innovative services.

The authors need to gain consensus in the IETF, that there is no other solution to the problem in hand, and hence that the significant restriction on the type of user application supported is justified.

=====

In addition this text should state that ANY system using this address
space MUST be capable of supporting the same address space
inside and outside (i.e. not just CPEs). 

Shared Address Space is distinct from [RFC1918] private address space
  because it is intended for use on Service Provider networks.
  However, it may be used as [RFC1918] private address space when at
  least one of the following conditions is true:

  o  Shared Address Space is not also used on the Service Provider side
      of the CPE.

  o  CPE routers behave correctly when using the same address block on
      both the internal and external interfaces.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP


The IESG has received a request from an individual submitter to consider the following document:
- 'IANA Reserved IPv4 Prefix for Shared CGN Space'
  as a BCP

On its December 15, 2011 telechat, the IESG reviewed version 10 of this
document and requested various changes. These changes are reflected in
the draft version 14 and the IESG now solicits community input on the
changed text only. Please send substantive comments to the ietf@ietf.org
mailing lists by 2012-02-16. Exceptionally, comments may be sent to
iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract

  This document requests the allocation of an IPv4 /10 address block to
  be used as Shared Address Space to accommodate the needs of Carrier
  Grade Network Address Translation (CGN) devices.  It is anticipated
  that Service Providers will use this Shared Address Space to number
  the interfaces that connect CGN devices to Customer Premise Equipment
  (CPE).

  Shared Address Space is distinct from RFC1918 private address space
  because it is intended for use on Service Provider networks.
  However, it may be used as RFC 1918 private address space in certain
  circumstances.  Details are provided in the text of this document.

  As this document proposes the allocation of an additional special-use
  IPv4 address block, it updates RFC 5735.

The following text captures the most salient change between version 10 and 14 of this document:

  Shared Address Space is IPv4 address space designated for Service
    Provider use with the purpose of facilitating CGN deployment.  Also,
    Shared Address Space can be used as additional [RFC1918] space when
    at least one of the following conditions is true:

    o  Shared Address Space is not also used on the Service Provider side
        of the CPE.

    o  CPE routers behave correctly when using the same address block on
        both the internal and external interfaces.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-weil-shared-transition-space-request/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-weil-shared-transition-space-request/


No IPR declarations have been submitted directly on this I-D.

[Ballot comment]
I am satisfied from the discussion on the IETF list that there is at least a reasonable risk to use current 1918 address space for this purpose, and though I do not believe that the proponents of making this new allocation have done enough due diligence to determine whether that risk is serious, I also believe that their fear of using 1918 space will cause them to either squat on a block, or use a private allocation for these purposes that is not documented. I would rather see a block set aside *and* documented rather than some other choice.

I also believe that the rewrite of this document in terms of Shared Address Space that can be used like any other 1918 address space *with the caveat* that it can be used in places that are normally reserved for public addresses sufficiently answers my concerns that we are making a technology-specific allocation for CGNs. This is general-use Shared Address Space, and I think the expansion of 1918 for these specific purposes is reasonable.

I still agree with Stewart's DISCUSS that sufficient consensus has not been established on the IETF list. I think this document (and the arguments I have laid out above) may hopefully move toward some consensus, but that has yet to be seen. However, I will allow Stewart to hold that DISCUSS. I would like to see this document back on a telechat at some point after we have a better handle on how rough the consensus on it is.

I have a few minor comments on the new revision, most of which I believe are vestiges of the earlier drafts:

Section 4:

  Shared Address Space MUST NOT be used for any purpose other than
  those stated above.

I think that sentence is incorrect. What I think you mean is that Shared Address Space MUST NOT be used unless the above conditions are met. I don't think you have to repeat that with 2119 language since it is already said above, so I suggest just dropping the sentence.

  Because CGN service requires non-overlapping address space on each
  side of the home NAT and CGN, entities using Shared Address Space for
  purposes other than for CGN service, as described in this document,
  are likely to experience problems implementing or connecting to CGN
  service at such time as they exhaust their supply of public IPv4
  addresses.

I also disagree with the above. Entities using Shared Address space *without following the above guidance* may experience problems, but not just because they're not CGNs. Again, I suggest you drop the above paragraph.

Section 5.2:

  As described in [RFC6269] and [I-D.donley-nat444-impacts], CGNs offer
  a reasonable quality of experience for many basic services including
  web, email, and Instant Messaging.  This is true regardless of
  whether the address range between the CGN and CPE is globally unique,
  Shared Address Space, or [RFC1918] space.  However, CGNs do adversely
  impact some advanced services, in particular:

I think the above is too much marketing for CGNs. A suggested reword:

  The primary motivation for the allocation of Shared Address Space is
  CGNs, and the use and impact of CGNs has been previously described in
  [RFC6269] and [I-D.donley-nat444-impacts]. Some of the services
  adversely impacted by CGNs are:

I think that sounds less defensive.

[Ballot discuss]
I believe there is not IETF Consensus for approving a /10 for this purpose, and, as a result, there is not IETF consensus to approve this document.

This document describes a number of problems that occur with CGN, even with this shared /10, so CGN does not make the Internet run better. I think there is IETF consensus that widespread deployment of CGN could be damaging to the Internet. I believe approving Shared CGN space to make CGN deployment easier is counter to the IETF mission of making the Internet run better, and approving allocation of this /10 does not represent IETF consensus.

[Ballot comment]
Based on list discussion, I have come to the conclusion that this is the least worst workaround (not "solution") available to us at this time.

[Ballot comment]
Based on more and more and more and more discussion I'm reluctantly
ok with this.

I think additionally allocating part of 240/4 would be a fine thing to do at
the same time within the same document. I would not be that keen on
punting on the 240/4 part allocation until later since that would engender
most of the same discussion.

[Ballot discuss]
While I personally agree with the position that approving this allocation is the least bad of the available choices, I don't believe IETF consensus for approving this document as it is currently written exists.

[Ballot comment]
I encourage pursuing Ralph's questions and carefully separating the question of allocating the address space and what effect CGNs may have on the Internet.

[Ballot discuss]
While I personally agree with the position that approving this allocation is the least bad of the available choices, I don't believe IETF consensus for approving this document as it is currently written.

[Ballot comment]
FWIW, the issue that I had with the previous incarnation of this document has been resolved. Thanks for working through the measurements and evidence about risks, and documenting them.

However, my fellow AD colleagues have raised other issues (including status of IETF consensus for this document). I defer to them on those issues.

[Ballot comment]
I agree with Ralph's DISCUSS: We need to first come up with a list of criteria by which consensus can be judged. While I agree with most folks that there is *disagreement* on the list as to whether this allocation should be made, I think some of the issues on which there is disagreement are not legitimate criteria for the consensus call. (For example, "Is CGN a viable service model for IPv4?" is *not* something that we should be using as a criteria for consensus.) Before we come to a conclusion on consensus, we need to lay out the legitimate issues being discussed and whether there is consensus on each of them.

[Ballot discuss]
Calling out one piece of Ralph's DISCUSS directly: I agree with Ralph and Stephen that the question of whether there is another existing block of addresses that will cause less potential application damage and is still usable by CGNs (e.g., 10.64/16, 172.16/12, 240/10) has not yet been sufficiently answered. The proponents have claimed that there is full *use* of the 1918 space, but not whether there is full use *by* devices that can't deal with 1918 address space on their "external" interfaces. Until that question is answered, we can't tell if the risk of application damage really is outweighed by the risk to deployment.

[Ballot discuss]
I believe there is not IETF Consensus for approving a /10, and there is not IETF consensus to approve this document.

This document describes a number of problems that occur with CGN. I believe CGN does not make the Internet run better, and approving Shared CGN space is counter to the IETF mission.
Widespread deployment would be damaging to the Internet.

Given the difficulties of reaching a subscriber's address from the global Internet, this would appear to add additional burden to establishing a VPN from, say, a hotel room to a user's home network.

Given that subscribers would share addresses, CGN could create serious security holes that need to be mitigated. The Security Considerations section does not discuss the issues and mitigation.

The document describes a number of alternatives to keeping IPv4 running longer, but  it appears IETF consensus has not been reached that this is a significantly better alternative than other approaches to extending IPv4.

The document describes a number of changes that would need to be to networking equipment to support the shared CGN space, and even with those changes, CGN would introduce significant problems to the Internet. It appears there would be a lot of work yet to be done to make CGN deployment make the Internet run better.

The IETF DOES have consensus on an alternative approach - IPv6. The document does not compare the problems introduced by CGN versus those introduced by IPv6, not does it compare the necessary equipment chnages for CGN support to the IPv6 alternative. Many of the issues of IPv6 have already been addressed, and much existing equipment is IPv6-ready. The document does not demonstrate why the CGN alternative would be technically superior to the IPv6 alternative.

I am interested in seeing answers to the many questions raised by the IETF.
Until the IETF reaches consensus that this is the right approach to IPv4 exhaustion, I expect to abstain rather than approve this document.

[Ballot comment]
Based on recent discussion, I agree with Ralph that the issue of whether or not
some other address space would work here (e.g. 240/10) needs to be clarified
before this should go ahead.

[Ballot discuss]
Ralph sumarized well and in details the reasons for which the IESG cannot approve this document under its current form and at this point in time. I  will probably change my DISCUSS into an Abstain after the telechat, unless we come with a different plan of action.

[Ballot discuss]
I am posting a Discuss position for this document because the IESG
should discuss some fundamental issues of how we should make a
decision about publication of this document.

I also have concerns about whether the IESG is the appropriate body to
approve this request.  I intend to post an Abstain position after
my questions are answered and I clear my Discuss.

The conversation about this document and any attempt to determine
consensus is difficult because the issues are technical, economic,
political and psychological.  We (the IESG) are well-equipped and
responsible for decisions about technical issues, but less so for the
other issues.

I've been reading most of the e-mail in the consensus call on
ietf@ietf.org.  Here are some of the questions I think I've seen
discussed:

  Does the assignment of the requested /10 enable or hinder the
  deployment of IPv6?

  Is CGN a viable service model for IPv4?

  Is the reserved /10 required for the deployment of CGN?

  Can the deployment of CGN be prevented by not assigning Shared CGN
  address space?

  What is the effect of burning 4 million IPv4 addresses on the
  exhaustion of IPv4?

  Can alternative /10s be used such as 10.64.0.0/10 or 240.0.0.0/10?

  How many ISPs really want this assignment and how many don't care
  because they don't need it?

Most of these questions are, in fact, not technical questions and I
don't think the IESG can answer them.  The document itself addresses
only a few issues, giving one reason not to use each of the
alternatives:

  o  legitimately assigned globally unique address space
  o  usurped globally unique address space (i.e., squat space)
  o  [RFC1918] space

In particular, the reason for not using RFC 1918 space is simply
asserted with no support facts.

If the IESG is to make a decision, I would like to walk through the
following questions:

  Is the IESG the appropriate body to make the decision?  If no, where
  should the decision be made, perhaps with technical advice from the
  IETF?

  Should the IESG identify any specific /10 for use as Shared CGN
  Space?  If no, do not approve the document.

  Does this document describe the usage scenarios, constraints and
  caveats sufficiently well to allow the use of a /10 as Shared CGN
  Space?  If no, ask for a revision.

  Should the IESG approve a request to IANA for a /10 as described
  in the document?  If yes, publish the document.

  Should the IESG request that IANA identify some other /10 (or
  similar address block), such as 172.16.0.0/12, 10.64.0.0/10 or
  240.0.0.0/10 for use as Shared CGN Space?

[Ballot comment]
I concur with Stewart that there does not appear to be IETF consensus around this I-D.

I am concerned that the alternative to this has been presented as "if you don't allocate the address space, the ISPs will just squat on another space." However, this also seems to be less worser than any other proposal on the table.

[Ballot discuss]
I understand the commercial imperatives that the ISPs face, and appreciate this is a dilemma.

However, the authors have not so far generated an adequate degree of consensus (as evidenced by discussions on the IETF list) that the deployment of this technology "makes the Internet work better". Indeed section 5 indicates that the deployment of this technology makes the Internet worse by reducing it to a network that only supports a limited range of services (Web, Mail and IM) sanctioned by the ISP. This seems contra to the mission of the IETF.

If this were a clearly defined limited application network, a case could be developed for accepting restrictions, but the application described here is connectivity to the Internet and hence access to new innovative services.

The authors need to gain consensus in the IETF, that there is no other solution to the problem in hand, and hence that the significant restriction on the type of user application supported is justified.

[Ballot discuss]
(revised in order to be more actionable)

As noted in the draft section 5.2, there are significant applications that break under CGN, and break because of the CGN regardless of whether this proposal is used or not.  ISPs which choose to deploy CGNs are providing an even lower grade of "Internet" service to their customers than when a single-level NAT is employed.  The incremental CGN RFC 6264 that is cited in this document is not just for IPv4, but also includes connection of the CGN to the IPv6 Internet and ability to provide IPv6 services to customers.  It is not clear whether this document intends to use the /10 to number dual-stack home gateways capable of using IPv6 or whether it only intends to use it for supporting IPv4 NAT444, which seems to be the case.  I believe if the allocation is made, it needs to specifically apply to CGNs which also support IPv6, in order to provide applications with the capability to run over IPv6 and potentially function properly.

There is an alternative not discussed in section 3 ... don't use CGN.  The use of this prefix for CGN needs to outweigh its use otherwise for public addresses, and the potential slowdown it enables in IPv6 transition.  This document in prior versions was attempting to motivate the allocation as aiding transition.  If additional private space is *not* made available to support CGN, and CGN is somewhat more cumbersome to deploy, will this aid transition?

The IETF has not finished producing requirements for CGN; it seems unlikely that CGNs deployed using this address space prior to that work completing would be fully compliant.  At minimum, the request for these prefixes at this point should be strongly motivated as to why it's needed now rather than after the CGN requirements have been completed and discuss the risks of deploying CGNs prior to having an established IETF consensus on the features that they need to have in order to increase the likelihood that applications will function properly.

There is not consensus for this document to-date on the IETF list.

[Ballot discuss]
As noted in the draft section 5.2, there are significant applications that break under CGN, and break because of the CGN regardless of whether this proposal is used or not.  ISPs which choose to deploy CGNs are providing an even lower grade of "Internet" service to their customers than when a single-level NAT is employed.  The incremental CGN RFC 6264 that is cited in this document is not just for IPv4, but also includes connection of the CGN to the IPv6 Internet and ability to provide IPv6 services to customers.  It is not clear whether this document intends to use the /10 to number dual-stack home gateways capable of using IPv6 or whether it only intends to use it for supporting IPv4 NAT444, which seems to be the case.  I believe if the allocation is made, it needs to specifically apply to CGNs which also support IPv6, in order to provide applications with the capability to run over IPv6 and potentially function properly.

There is an alternative not discussed in section 3 ... don't use CGN.  The use of this prefix for CGN needs to outweigh its use otherwise for public addresses, and the potential slowdown it enables in IPv6 transition.  This document in prior versions was attempting to motivate the allocation as aiding transition.  If additional private space is *not* made available to support CGN, and CGN is somewhat more cumbersome to deploy, will this aid transition?

The IETF has not finished producing requirements for CGN; it seems unlikely that CGNs deployed using this address space prior to that work completing would be fully compliant.  At minimum, the request for these prefixes at this point should be strongly motivated as to why it's needed now rather than after the CGN requirements have been completed and discuss the risks of deploying CGNs prior to having an established IETF consensus on the features that they need to have in order to increase the likelihood that applications will function properly.

There is not consensus for this document to-date on the IETF list.

[Ballot discuss]
As noted in the draft section 5.2, there are significant applications that break under CGN, and break because of the CGN regardless of whether this proposal is used or not.  ISPs which choose to deploy CGNs are providing an even lower grade of "Internet" service to their customers than when a single-level NAT is employed.  The incremental CGN RFC 6264 that is cited in this document is not just for IPv4, but also includes connection of the CGN to the IPv6 Internet and ability to provide IPv6 services to customers.  It is not clear whether this document intends to use the /10 to number dual-stack home gateways capable of using IPv6 or whether it only intends to use it for supporting IPv4 NAT444, which seems to be the case.

There is an alternative not discussed in section 3 ... don't use CGN.  The use of this prefix for CGN needs to outweigh its use otherwise for public addresses, and the potential slowdown it enables in IPv6 transition.  This document in prior versions was attempting to motivate the allocation as aiding transition.  If additional private space is *not* made available to support CGN, and CGN is somewhat more cumbersome to deploy, will this aid transition?

The IETF has not finished producing requirements for CGN; it seems unlikely that CGNs deployed using this address space prior to that work completing would be fully compliant.  At minimum, the request for these prefixes at this point should be strongly motivated as to why it's needed now rather than after the CGN requirements have been completed and discuss the risks of deploying CGNs prior to having an established IETF consensus on the features that they need to have in order to increase the likelihood that applications will function properly.

There is not consensus for this document to-date on the IETF list.

[Ballot discuss]
As noted in the draft section 5.2, there are significant applications that break under CGN, and break because of the CGN regardless of whether this proposal is used or not.  ISPs which choose to deploy CGNs are providing an even lower grade of "Internet" service to their customers than when a single-level NAT is employed.

There is an alternative not discussed in section 3 ... don't use CGN.  The use of this prefix for CGN needs to outweigh its use otherwise for public addresses, and the potential slowdown it enables in IPv6 transition.  This document in prior versions was attempting to motivate the allocation as aiding transition.  If additional private space is *not* made available to support CGN, and CGN is somewhat more cumbersome to deploy, will this aid transition?

The IETF has not finished producing requirements for CGN; it seems unlikely that CGNs deployed using this address space prior to that work completing would be fully compliant.  At minimum, the request for these prefixes at this point should be strongly motivated as to why it's needed now rather than after the CGN requirements have been completed and discuss the risks of deploying CGNs prior to having an established IETF consensus on the features that they need to have in order to increase the likelihood that applications will function properly.

There is not consensus for this document to-date on the IETF list.

[Ballot discuss]
As noted in the draft section 5.2, there are significant applications that break under CGN, and break because of the CGN regardless of whether this proposal is used or not.  For that reason, I do not think that CGN is a desirable technology to deploy, and this document presumes that CGN is something which should be deployed.

There is an alternative not discussed in section 3 ... don't use CGN.  The use of this prefix for CGN needs to outweigh its use otherwise for public addresses, and the potential slowdown it enables in IPv6 transition.  This document in prior versions was attempting to motivate the allocation as aiding transition.  If additional private space is *not* made available to support CGN, and CGN is somewhat more cumbersome to deploy, will this aid transition?

The IETF has not finished producing requirements for CGN; it seems unlikely that CGNs deployed using this address space prior to that work completing would be fully compliant.  At minimum, the request for these prefixes at this point should be strongly motivated as to why it's needed now rather than after the CGN requirements have been completed and discuss the risks of deploying CGNs prior to having an established IETF consensus on the features that they need to have in order to increase the likelihood that applications will function properly.

There is not consensus for this document to-date on the IETF list.

[Ballot discuss]
As noted in the draft section 5.2, there are significant applications that break under CGN, and break because of the CGN regardless of whether this proposal is used or not.

There is an alternative not discussed in section 3 ... don't use CGN.  The use of this prefix for CGN needs to outweigh its use otherwise for public addresses, and the potential slowdown it enables in IPv6 transition.  This document in prior versions was attempting to motivate the allocation as aiding transition.  If additional private space is *not* made available to support CGN, and CGN is somewhat more cumbersome to deploy, will this aid transition?

The IETF has not finished producing requirements for CGN; it seems unlikely that CGNs deployed using this address space prior to that work completing would be fully compliant.  At minimum, the request for these prefixes at this point should be strongly motivated as to why it's needed now rather than after the CGN requirements have been completed and discuss the risks of deploying CGNs prior to having an established IETF consensus on the features that they need to have in order to increase the likelihood that applications will function properly.

There is not consensus for this document to-date on the IETF list.

[Ballot discuss]
As noted in the draft section 5.2, there are significant applications that break under CGN, and break because of the CGN regardless of whether this proposal is used or not.

There is an alternative not discussed in section 3 ... don't use CGN.

The IETF has not finished producing requirements for CGN; it seems unlikely that CGNs deployed using this address space prior to that work completing would be fully compliant.

There is not consensus for this document to-date on the IETF list.

[Ballot discuss]
"NAT4444" should be "NAT444", I believe, in section 1, paragraph 3.

As noted in the draft section 5.2, there are significant applications that break under CGN, and break because of the CGN regardless of whether this proposal is used or not.

There is an alternative not discussed in section 3 ... don't use CGN.

The IETF has not finished producing requirements for CGN; it seems unlikely that CGNs deployed using this address space prior to that work completing would be fully compliant.

There is not consensus for this document to-date on the IETF list.

IANA understands that, upon approval of this document, there is a single
IANA action which must be completed.

IANA will record an allocation of an IPv4 /10 for use as Shared CGN Space.

IANA notes that there is a placeholder in the IANA Actions section for
the prefix to be recorded when it is known, so that the RFC Editor can
add it after IANA has recorded the assignment.

IANA understands that this is the only action that is required to be
completed upon approval of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (IANA Reserved IPv4 Prefix for Shared CGN Space) to BCP


The IESG has received a request from an individual submitter to consider
the following document:
- 'IANA Reserved IPv4 Prefix for Shared CGN Space'
  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@ietf.org mailing lists by 2011-11-07. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document requests the allocation of an IPv4 /10 address block to
  be used as Shared Carrier Grade Network Address Translation (CGN)
  Space.  Service Providers will use Shared CGN Space to number the
  interfaces that connect CGN devices to Customer Premise Equipment
  (CPE).  As this document proposes the allocation of an additional
  special-use IPv4 address block, it updates RFC 5735.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-weil-shared-transition-space-request/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-weil-shared-transition-space-request/


No IPR declarations have been submitted directly on this I-D.

[Ballot comment]
The current version of the document address my DISCUSS comment in that it now says directly that this is to address broken CPE devices that can't deal with 1918 addresses on the "inside" *and* "outside" interfaces. I have no reason to doubt that this is true. However:

1. I do agree with Jari's DISCUSS that whether this proposal will cause *additional* damage by breaking certain apps that try to work around NATs (e.g., Skype, apps that use STUN, etc.) is not sufficiently addressed in this document (or for that matter draft-bdgks-arin-shared-transition-space). I think there needs to be some discussion of whether the cure is worse than the disease. I am willing to believe that it is not, but the document needs to address the issue.

2. I remain unconvinced that the new addresses "MUST NOT be utilized for any purpose other than as 'inside' addresses in a CGN environment" is a necessary requirement. So long as anything using these addresses deals with the possibility that these addresses can be use by providers as CGN addresses, there is no reason they couldn't be used for 'inside' addresses of a NAT: 1918 addresses could have been used for CGNs if not for the fact that CPE devices don't deal with the possibility of identical addresses on the inside and the outside.

[Ballot discuss]
I reviewed this document as a part of IESG document approvals this week.

I have to say that I found it difficult to decide whether to recommend the approval of this or not. We are in a difficult position, out of addresses, having to deploy NAT444, having to choose between the bad and even worse alternatives. It is hard for me to evaluate whether the proposed allocation will reduce pain more than it will cause pain elsewhere. In other words, is this making the Internet work better.

But there is clearly consensus in the operator community that we need this. However, I have one concern. The document is quite silent on the impacts. And there are negative impacts. For instance, anything that today checks for RFC 1918 space is potentially going to get a wrong answer tomorrow unless the code is changed to support the new private address space. And I don't know what things might be impacted. It is certainly possible for hosts to attempt to discover their externally visible IP addresses, query their access router for its external address, employ address testing in their NAT traversal solution (most non-trivial applications have one), and so on.

I did a quick check with a few pieces of software and found out that in at least some fraction of them there seems to be code that is testing for this stuff. I looked at the Linux kernel source, Asterisk SIP server, Skype, and the Chromium browser. I looked for decimal 192 and 168 on the same line either in the source code or strings from binaries, and then looked at the found instances myself to understand what they might be about. Skype produced an inconclusive or negative answer, I did not find these patterns in the binary. Asterisk clearly had code for testing addressing, hard coded to the current RFC 1918 addresses. Chromium had  strings for 10/8 and 192.168/16 but it was hard to tell what it is using them for. Linux kernel used these addresses in many places but as far as I could tell, none of them were about testing, so they might be fine.

So what breaks if a test goes wrong? The true answer is that I don't know. But it is certainly possible that an application ends up not working because it chose to use an address that is not globally visible, or that some delays are incurred when addresses are tested in suboptimal order. And so on. Draft-well has a companion document, draft-bdgks, which sort of mentions this issue but dismisses it as bad implementation assumptions. I do not believe that is an appropriate assessment in a world where RFC 1918 status has been stable for a long time, and per evidence above, software in general seems to hardcode these addresses. This is reality, we need to face it. Draft-bdgks makes a much better argument when it states that the allocation of the new address space does not really change the impacts in this respect if NAT444 is deployed anyway but just using some otherwise agreed or bogon address space. This is true, but I think the official approval of new space from the IETF and
ARIN will make this practice more widely known and used. It is our responsibility to deal with the impacts.

So here's what I would like to propose. The document goes forward but we make a much clearer statement with regards to the implications both for applications out there, as well as for subsequent IETF work:

- what types of impacts may be felt by the rest of the network (not the ISP that is deploying NAT444)
- what kinds of application practices may be affected
- what IETF specifications may need revision due to this (e.g., do we need to revise ICE etc)

(It would have been even better if we had access to research that has looked at the various impacts in a rigorous manner. E.g., what's the likelihood of ISP - subscriber address collision in the different parts of the current RFC 1918 space vs. what is the likelihood of application failures with the new space. Not sure if we have time for that research now unless it already exists.)

[Ballot comment]
I support the many Discusses raised by other ADs and do not feel the
need to raise any more Discuss issues myself.

I find myself strongly disagreeing with the statement that service
providers do not have the ablity to influence the rate of replacement
of deployed customer equipment. Firstly, the availability of native
IPv6 services is a prerequisite for anyone bothering to upgrade - this
is clearly in the hands of the service providers and remarkably little
effort has been made to provide such services. Secondly, a large
proportion of home routrs are supplied via the service providers as
part of the sign-up deal - these have become almost as replacable as
moble phones. Thirdly, I would point to the tansition from analogue to
digital terestrial TV in some countries - a change that has been forced
on the consumer in a relatively short period (albeit with regulatory
backup) and which has obsoleted the installed base of far more expensive
customer equipment.

In effect, ts document would be far more likely to get a smooth passage
if it did not try to give reasons or excuses, but simply said what is
required and for what purpose.

[Ballot discuss]
1) I'd like to see some more text after the following sentence:

  Reverse DNS queries for
  Shared Transition Space addresses MUST NOT be forwarded to the global
  DNS infrastructure.

Maybe something like:

  This is done to avoid having to set up something similar to AS112.net for
  RFC 1918 private address space that a host has incorrectly sent for a
  DNS reverse-mapping queries on the public Internet [RFC6304].

I'd really hate for this to lead to an expansion of that "fix" (or maybe I'm totally misunderstanding what you're asking for).

2) The secdir review pointed out the following:

  Following up on draft-bdgks, the current document should at least
  advise on (and better yet, mandate solutions for) "best practices
  associated with the use of this space, including considerations
  relating to filtering, routing, etc.".

Can something be added to address this?

IANA has concerns about the IANA Actions in this document

IANA believes that this should be a BCP or standards track document and
not just Informational.

In addition, IANA believes that there should be a placeholder in the
IANA Actions section for the prefix to be recorded when it is known, so
that the RFC Editor can add it after we have recorded the assignment.

Finally, IANA has discussed other issues with the authors in Last Call.

[Ballot discuss]
I agree with Wes's DISCUSS. This has nothing to do with IPv6 transition. This is a new special-use NAT address space. In particular, though I understand that much of the justification for this is in draft-bdgks-arin-shared-transition-space, I think this document at least needs to explicitly say that the requesters have actual knowledge that there are uses for this address space (e.g., using it on the "outside facing" interface of current NATs) that will fail miserably if current 1918 space (either 10/8, 172.16/12, or 192.168/16) is used. If this is simply a guess that too many things will break, I'm not as happy about going forward with the allocation. If it is actually known that things will break, the document should say that.

[Ballot comment]
I agree with Russ's DISCUSS (as does IANA apparently).

I agree with Wes's DISCUSS. In particular, though I understand that much of the justification for this is in draft-bdgks-arin-shared-transition-space, I think this document at least needs to explicitly say that the requesters have actual knowledge that there are NATs out there that will fail miserably if current 1918 space (either 10/8, 172.16/12, or 192.168/16) is used on the "outside facing" interface. If this is simply a guess that too many things will break, I'm not as happy about going forward with the allocation. If it is actually known that things will break, the document should say that.

It seems to me that the IAB should weigh in on this document.

[Ballot discuss]
The authors state that there are no security issues because no protocol is defined. However the last para of section4
instructs certain filtering operations and indicates that under some circumstances these filtering operations may be relaxed. That is a type of protocol action which I would have expected to be considered from a security perspective.

I wish to discuss the following on the IESG call. At the moment there is no action for the authors.

I share Wesley's concern that this address space will just be used as yet more generic NAT space. If the space is to be used for the IPv6 transition it would  be better if it were normatively bound to a set of named transition mechanisms.

[Ballot discuss]
I don't plan to hold this DISCUSS past the telechat.

This document says the prefix will be used to support IPv6 transition and coexistence with IPv4.

I think it has little or nothing to do with IPv6, at least based on the text and cited documents.

Most (or all) of the rationale really seems to be contained in draft-bdgks-arin-shared-transition-space.  Looking at that document makes it seem like the motivation really boils down to this new space supporting all sorts of IPv4-only ISP concerns without direct links to IPv6 transition (sections 3.1 through 3.5 have nothing to do with transition), but it will "free up time" for operators to think about transition (section 3.6).

The policy statement actually makes it pretty clear that this is more about IPv4 extension than transition:
  A second contiguous /10 IPv4 block will be reserved to facilitate
  IPv4 address extension.  This block will not be allocated or assigned
  to any single organization, but is to be shared by Service Providers
  for internal use for IPv4 address extension deployments until
  connected networks fully support IPv6.  Examples of such needs
  include: IPv4 addresses between home gateways and NAT444 translators.

I suspect many people will use this prefix without spending any time thinking about IPv6 or working on transition.  I suppose there's no way to tie the use of this prefix to only operators that are also running some form of IPv6 trial or operational service.

I think the title and text using "shared transition space" terminology are misleading.  It should really be called what it is: "additional NAT space", "additional IPv4 private addresses", or something similar.  I feel like we're only pretending that it has something to do with IPv6 to make it more palatable.

[Ballot discuss]
I don't plan to hold this DISCUSS past the telechat.

This document says the prefix will be used to support IPv6 transition and coexistence with IPv4.

I think it has little or nothing to do with IPv6, at least based on the text and cited documents.

Most (or all) of the rationale really seems to be contained in draft-bdgks-arin-shared-transition-space.  Looking at that document makes it seem like the motivation really boils down to this new space supporting all sorts of IPv4-only ISP concerns without direct links to IPv6 transition (sections 3.1 through 3.5 have nothing to do with transition), but it will "free up time" for operators to think about transition (section 3.6).

The policy statement actually makes it pretty clear that this is more about IPv4 extension than transition:
  A second contiguous /10 IPv4 block will be reserved to facilitate
  IPv4 address extension.  This block will not be allocated or assigned
  to any single organization, but is to be shared by Service Providers
  for internal use for IPv4 address extension deployments until
  connected networks fully support IPv6.  Examples of such needs
  include: IPv4 addresses between home gateways and NAT444 translators.

I suspect many people will use this prefix without spending any time thinking about IPv6 or working on transition.  I suppose there's no way to tie the use of this prefix to only operators that are also running some form of IPv6 trial or operational service.

I think the title and text using "shared transition space" terminology are misleading.  It should really be called what it is: "additional NAT space", "additional IPv4 private addresses", or something similar.

[Ballot comment]
- Wouldn't it be useful to note that this UPDATEs 1918?  Just so that
people going there for the bogon list get to find out about the new
allocation as well?

- What is the exception for rule that packets with these addresses as
source or destination  "SHOULD NOT be forwarded" across interdomain
links? Clarifying that would be useful.

- Why is filtering routing information for these addreses on ingress
links not a MUST? Put another way, what's the exception to the
SHOULD rule? Clarifying that would be useful.

editorial:
- abstract missing a "." at the end
- expand acronyms on 1st use: CGN, CPE
- capitalisation is inconsistent for "Infrastructure Provider" and
"Shared Transition Space"

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'IANA Reserved IPv4 Prefix for Shared Transition Space'
  as an Informational
RFC

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@ietf.org mailing lists by 2011-09-16. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document requests a reserved IANA IPv4 address allocation as
  Shared Transition Space to support the deployment of IPv4 address
  sharing technologies post IPv4 exhaustion




The file can be obtained via
http://datatracker.ietf.org/doc/draft-weil-shared-transition-space-request/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-weil-shared-transition-space-request/


No IPR declarations have been submitted directly on this I-D.