[Bp_ipv6] Comments on the baseline draft of Background Paper
Chip Sharp (chsharp)
chsharp at cisco.com
Thu Aug 27 17:17:29 EDT 2015
Dear Susan, all,
I understand that the current draft is frozen until after the MAG meeting and that I’ll need to submit any proposed edits after it is re-opened for comment. There are a few technical edits that could be made (e.g., IP addresses identify interfaces, not devices.).
Below are some general comments, I guess as a heads-up.
Scope of background information:
It is my understanding that this is a background document to be used in the discussion and that there will be a follow-on discussion on what recommendations to make. There are several places in the document that cross over from background information to recommendations and advocacy, e.g., "IPv6 compliance should also be mandated”, "placing IPv6 lower in priority than it should be”, "should provide more IPv6-capable products,” "should support IPv6 straight out of the box."
These types of recommendations and conclusory statements should be removed from the document. The document should only include background information and not pre-judge the discussion on recommendations for an enabling environment.
Use of terms “compliance” and “compliant”
The document should find terms to use other than these, e.g., “IPv6 capable” or “IPv6 support”. The Apple announcement referenced in the document uses the term “IPv6 support” not “IPv6 compliant”. The term “compliance” has a particular regulatory meaning related to Conformity Assessment and Type Approval and its use could be misleading. For example, at least one regulator has already initiated a program for Conformity Assessment and Type Approval of IPv6 equipment (see my comment on cost below).
IPv4’s Secondary Market:
I agree with the general message that the IPv4 market is not a long-term solution for IPv4 address shortage. No matter how IPv4 address space is sliced and diced the overall pool doesn’t increase. In general, I’d recommend not going into this in too much detail.
For completeness, the document should indicate that the Regional Internet Registries have developed policies for IPv4 address transfers and that those policies were developed under their Policy Development Process. The current draft leaves the impression that the RIRs have not addressed this. Each RIR has published its policy on address allocation, e.g., RIPE-NCC: https://www.ripe.net/publications/docs/ripe-606. A reference to these policies should be referenced at least in the Address Management section.
There was a question about references for routing problems. Endnote 15 already describes this so we don’t need a new reference:
There was also a question on problems with geolocation. It is a little more difficult to find a neutral description. The Dyn article touches on the issue.
You could try Wikipedia - https://en.wikipedia.org/wiki/Geolocation_software
CAIDA has a more comprehensive discussion,
The text on NAT/CGN focuses exclusively on IPv4 to IPv4 NAT (NAT44). Network Address Translation also plays an important role in deploying IPv6 in conjunction with IPv4 and allowing IPv4 and IPv6 to interwork (e.g., IPv6-only client to access an IPv4-only server and vice versa). This use of NAT/CGN should also be mentioned. The concerns in the 2nd paragraph still apply.
IMO, an important hurdle that should be emphasized more across all subsections is cost and the need for businesses to manage cost of investment vs. revenue (near-term and projected long-term). The demand side of the problem should also be highlighted.
Bitstream/Wholesale Access Provider
* Bitstream/wholesale providers use access technologies other than fiber (e.g. DSL) so I don’t think this needs to be limited to fiber.
* This subsection focuses on monopoly providers, but even in a market where there is competition there would also be switching costs associated with moving from a provider that doesn’t support IPv6 and one that does (see my comment on cost).
* We also need to look at this from the bitstream provider’s perspective. A bitstream/wholesale provider could face capital and operational expenses to support IPv6, much like a retail provider (see comment on cost above). Or are you saying that the bitstream provider is actively blocking IPv6?
BTW, not necessary to include in the paper, but I’m curious why a bitstream provider would not be transparent to Layer 3.
Compliant hardware and software:
Whether you call IPv6 a “feature request” or a “baseline”, the developer still has to make a cost/benefit analysis when allocating resources. This section ignores the fact that there is a cost associated with developing IPv6 in hardware and software (see my comment on cost). Also, my comment above about recommendations and conclusory language applies to this section.
More information about the Bp_ipv6