[Bp_ipv6] Comments on the baseline draft of Background Paper
pwilson at apnic.net
Fri Aug 28 00:50:48 EDT 2015
Nice to see you here.
By my understanding of its purpose, this document really doesn’t need
to distinguish between devices and interfaces. But if we want to avoid
alienating the better-informed, perhaps a footnote is the right place to
explain that finer point. IMHO. :-)
Having inserted the point about Apple’s policy, I agree completely
with your suggestion to avoid “compliant” and variations - to avoid
implication of “authorities”. Much better to use “support”.
Finally, happy with your suggestion re IPv4 secondary market: it is
important for immediate short-term business needs; but in the scheme of
things, just a way of shuffling the deck chairs.
On 28 Aug 2015, at 7:17, Chip Sharp (chsharp) wrote:
> 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
> 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 -
> 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.
> Bp_ipv6 mailing list
> Bp_ipv6 at intgovforum.org
Paul Wilson, Director-General, APNIC dg at apnic.net
More information about the Bp_ipv6