Subject: draft-azinger-cidrv6-00

From: Leo Vegoda <[email-masked]>
Date: Tue, 20 Jul 2010 15:13:16 -0700

Hi,

I have been reading draft-azinger-cidrv6-00 and have a couple of comments on it for the list.

Firstly, in section 4, I think it would be useful to note that RIRs should aim to aggregate an ISPs second and later allocation with earlier allocations. I believe this is already done but it would be good to recommend it. I'd like to suggest the second sentence below be added.

"RIRs initial and subsequent allocation policy to service providers should allow for a minimum of 2 years worth of usage based on historical or business plan projections. Further, RIRs should implement practices that maximise the potential for subsequent allocations to be made contiguous with previous allocations."

Also, in section 10 it is recommended that "Internet Registries should severely limit or eliminate [...] PI assignments". There are obviously reasons for the current policies allowing IPv6 PI assignments but the potential for significant routing table growth has not been removed, so I wonder whether it would make sense to request the RIR communities to review the impact of PI assignment policies on the rate of routing table growth on a regular basis. 

Regards,

Leo

---

From: Tony Li <[email-masked]>
Date: Wed, 21 Jul 2010 23:12:27 +0200

Hi Leo,

> Also, in section 10 it is recommended that "Internet Registries should severely limit or eliminate [...] PI assignments". There are obviously reasons for the current policies allowing IPv6 PI assig…

The authors concur and unless there is some dissent from the list, we'll amend accordingly.

Tony

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 22 Jul 2010 00:03:35 +0100

On 20/07/2010 23:13, Leo Vegoda wrote:
> Also, in section 10 it is recommended that "Internet Registries
> should severely limit or eliminate [...] PI assignments".

RIRs carry out the policies set by their constituents, and cannot 
arbitrarily limit assignments unless there is scope within their 
policies to do so

In addition, until such time as there is a viable alternative for 
end-user multi-homing in ipv6, I'm not sure if making a recommendation 
like section 10 is actually going to achieve anything - other than 
raising eyebrows.

Section 5.2: Projections.

Um, I don't believe that a projection for 2040 adds anything here.  As 
the authors note, an S curve seems more likely at this stage, so adding 
an arbitrary number which is a similar order of magnitude to the 
population of the earth doesn't really lend credibility to the table :-)

Section 5.1: Analysis.

>    Thus, the bulk of the routing table growth appears to be due to PI
>    prefix injection.

No doubt it is.  Provider level aggregation will ensure that the N 
provider associated prefixes that most providers have been allocated 
today will be be reduced to 1.  Would it be useful to adopt a potential 
modeling premise that posits that most PI ipv4 holders today will take 
out an ipv6 block in the future, and see where that leads?

Section 5:  it may be useful to flesh out traffic engineering issues 
here.  This has the potential to increase prefix numbers from 1 back to 
N, and my gut feeling is that this is going be the #2 prefix source 
after PI.

Nick

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Jul 2010 17:28:19 +1200

> like section 10 is actually going to achieve anything - other than

Other eyebrows are already raised by the prospect of ten million
BGP4 routes. It's really odd that the RIR constituencies aren't more
worried about that.

    Brian

---

From: Tony Li <[email-masked]>
Date: Thu, 22 Jul 2010 10:09:40 +0200

Hi Nick,

> RIRs carry out the policies set by their constituents, and cannot arbitrarily limit assignments unless there is scope within their policies to do so

The whole point is to give the RIRs the technical requirements so that they can set effective policies.

> In addition, until such time as there is a viable alternative for end-user multi-homing in ipv6, I'm not sure if making a recommendation like section 10 is actually going to achieve anything - other than raising eyebrows.

As you may know, there are several proposals being discussed.  Our point is to raise the issue with RIRs and ensure that they understand that this technology is becoming available.

> Um, I don't believe that a projection for 2040 adds anything here.  As the authors note, an S curve seems more likely at this stage, so adding an arbitrary number which is a similar order of magnitude to the population of the earth doesn't really lend credibility to the table :-)

Again, we are not claiming that this will be the growth rate.  We are simply pointing out the mathematical implications of a sustained 54% rate.  The number is not arbitrary in the least, it simply shows the implications of where we might be in 30 years.

> No doubt it is.  Provider level aggregation will ensure that the N provider associated prefixes that most providers have been allocated today will be be reduced to 1.  Would it be useful to adopt a potential modeling premise that posits that most PI ipv4 holders today will take out an ipv6 block in the future, and see where that leads?

Obviously, that leads us to a baseline of 350K routes.  If done quickly, that would accelerate the growth rate.

> Section 5:  it may be useful to flesh out traffic engineering issues here.  This has the potential to increase prefix numbers from 1 back to N, and my gut feeling is that this is going be the #2 prefix source after PI.

I concur that it will be a contributor.  TE is already discussed in the problem statement (draft-narten-radir-problem-statement-05).

Tony

---

From: Fred Baker <[email-masked]>
Date: Thu, 22 Jul 2010 04:20:48 -0400

On Jul 22, 2010, at 1:28 AM, Brian E Carpenter wrote:
> Other eyebrows are already raised by the prospect of ten million BGP4 routes. It's really odd that the RIR constituencies aren't more worried about that.

Well, there are mitigations. They know how to aggregate routes, they now have routers with actual memory in them, links and processing are fast enough that they don't see delays in convergence induced from that source (convergence delays continue to happen, but other reasons are more dominant).

I think your average ISP tends to think that his vendors will solve that.

Speaking from the perspective of one of the obvious vendors, I'm certainly willing to sell them memory as well; that's "just capex", expensive and something they love to hate, but a one-time purchase. And, by the way, not a primary driver of the cost of equipment - there are other things much more expensive than memory.

What is driving the RIR discussions is the desire of edge networks to be independent of their providers, not captive to them. They don't want to have to adjust (renumber, reroute) their networks when they change providers. The fundamental failing of shim6 (and for that matter, of lisp) is that it moves a lot of complexity from the transit networks, who know how to manage it, to the edge networks, who don't. Yes, it minimizes the number of routes in the transit domains by making them provider-allocated; it maximizes the routing for the edge network, because there are multiple instances of an almost-identical route for each subnet in the edge domain. The edge networks see a provider tie and more-complex routing as net negatives.

That is what is driving the discussion of ILNP etc. GSE enables the transit domains to have the relative simplicity of a PA network while giving the edge networks the relative simplicity of a PI prefix, and all the while enabling any system in the network to reliably address any other system in the network (unlike IPv4/IPv4 NAT) using a stateless (and therefore load-sharable and stable) prefix translation. There are some applications one doesn't run across prefix translation boundaries (anything that carries and cares about the prefix) and some things sensible people do in applications (SIP and HTTP refers use names, not addresses, for example); if you obey the rules, it works, and if you don't, you created your problem and you know how to solve it.

---

From: Fred Baker <[email-masked]>
Date: Thu, 22 Jul 2010 04:27:16 -0400

> Again, we are not claiming that this will be the growth rate.  We are simply pointing out the mathematical implications of a sustained 54% rate.  The number is not arbitrary in the least, it simply…

Personally and speaking for myself, I don't see why the 54% growth rate would be sustained. Basically, you have a lot of folks that don't have an IPv6 prefix but that have an IPv4 prefix mirroring their IPv4 connectivity. I would expect IPv6 prefix growth to be similar to IPv4 prefix growth in the long haul, not to vastly outweigh it.

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 22 Jul 2010 14:43:02 +0100

> they can set effective policies.

This is a sensible approach, although Fred really hit the nail on the head 
in his previous email ("What is driving the RIR discussions...").

> Again, we are not claiming that this will be the growth rate.  We are
> simply pointing out the mathematical implications of a sustained 54%
> rate.  The number is not arbitrary in the least, it simply shows the
> implications of where we might be in 30 years.

I meant arbitrary cut-off point rather than arbitrary number, but look, 
this is a bike-shed issue. The point I was trying to make was that having a 
malthusian growth table doesn't really add anything to the I-D, which 
brings us back to your point above.  If the RIRs need to be given technical 
ammo to help them formulate aggregation and dfz prefix-count limitation 
policies, then the more realistic the models provided, the more likely 
people will be to pay attention to them.  A demonstration of unconstrained 
exponential growth is not useful from this point of view.

Nick

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 22 Jul 2010 08:33:21 -0700

Fred,

Please see below for my review of this document.
Fred B. suggested posting this directly to the list.

Thanks - Fred
[email-masked]

Review of 'draft-ietf-v6ops-tunnel-security-concerns-02'
********************************************************

1) Section 2.1.1, on first use of the terms the document should
say more about what is meant by "defense in depth" and "security
gaps". Is it about ingress filtering? Is it about something else?

2) Section 2.2.2, please cite RFC2827 and RFC3704 upon first
mention of ingress filtering. Also check that the terms ingress
and egress are being used in the correct way. For example,
RFC2827 refers to ingress filtering as checking the outgoing
source address, which seems to be the opposite of what is being
represented in this document.

3) Section 2.2.2, sentence structure at end of first sentence.
Suggest changing to: "... are done to mitigate attacks and to
make it easier to identify the source of a packet; they are
also considered to be a good practice."

4) Throughout the document, it seems that there is an assumption
that only host<->host and host<->router tunneling is considered,
i.e., it does not seem to consider router<->router tunneling. In
particular, the use of the term "tunnel client" seems to always be
associated with a host and not another router. Is router<->router
tunneling considered as out-of-scope for this document? The
document should state the scope up front.

5) Section 3.1.2, first sentence of final paragraph, change to
"The other approach is to find tunneled packets to block in the
same way as would be done for inspecting native packets (Section
3.2)."

6) Section 3.1.2, final sentence of final paragraph, change to
"However, this faces the same difficulties..."

7) Section 3.2.2, first sentence of third paragraph, change
to "The implication of this latter case is that ..."

8) Section 3.2.3, first sentence, change to "As illustrated
above, it should be clear that inspecting the contents of
tunneled data packets that are not easily identified (e.g.,
those without a well-known UDP or TCP port) is highly
complex ..."

9) Section 4.1.2, paragraph beginning "(By the virtue of the
tunnel ... based on the outer IP.)". It seems odd to see a
new paragraph beginning with a parenthetical sentence. Also,
the paragraph itself seems to have excessive parentheticals.

10) Section 4.2.2, item 1. This concern is true not only for
tunnels but also for any service that keeps a NAT port open
indefinitely, for example through static administrative
configuration. NAT pin-holing concerns are therefore a
more broad-reaching subject and not specific to tunnels. 

11) Section 4.2.2, item 2, final sentence, this concern is
specific to the native routing and addressing of the inner
network layer protocol, so the use or non-use of tunneling
to reach the inner network layer destination is irrelevant.
Suggest removing this sentence.
  
12) Section 4.2.2, item 3, change first sentence to "The
tunnel protocol may contain more messages..." since the
use of tunneling does not always result in more messages
and longer path lengths.

13) Sections 4.1.3, 4.2.3 and 4.3.3, the recommendations
seem too broad. Minimization of some types of tunnels may
be appropriate, while use of other tunnel types may be
beneficial and not subject to these broader concerns.

14) Section 6.1, this section seems to assume reliance on
the DNS and bases some of the vulnerabilities on the
possibility for DNS spoofing. However, if the tunnel client
has a way to determine tunnel server addresses via some
secure means that does not involve the DNS then some
aspects of these vulnerabilities are mitigated. Perhaps
this can be captured in Section 6.1.3 in some way.

15) Section 7, final sentence before bulleted list, change
to "Several measures can be taken in order to secure the
operation of IPv6 tunnels, including:"

---

From: David Conrad <[email-masked]>
Date: Thu, 22 Jul 2010 11:00:31 -0700

> BGP4 routes. It's really odd that the RIR constituencies aren't more

It is the RIR constituencies that are creating and approving the policies that are encouraging that prospect.  Relying on the RIRs to protect the routing system is ... questionable since the RIR's role is (should be?) limited to the allocation and recording of registration information about those allocations.  Efforts by the RIRs to implement policies that limit de-aggregation or deny provider independent space to leaf networks has generally (and not surprisingly) resulted in those polices being rejected by the RIR communities.  

With the likely proliferation of multi-homing in the future (since people will be becoming more and more dependent on the Internet always being available) not to mention the likely result of market forces encouraging deaggregation of IPv4 address blocks, I'm guessing 10 million BGP4 routes is likely to be optimistic...

Regards,
-drc

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 22 Jul 2010 16:46:52 -0700

Hi Tony,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Tony Li
> Sent: Wednesday, July 21, 2010 2:12 PM
> To: Leo Vegoda
> Cc: IPv6 Operations
> Subject: Re: draft-azinger-cidrv6-00
> 
> 
> Hi Leo,
> 
> > Firstly, in section 4, I think it would be useful to note that RIRs should aim to aggregate an ISPs
> second and later allocation with earlier allocations. I believe this is already done but it would be
> good to recommend it. I'd like to suggest the second sentence below be added.
> >
> > "RIRs initial and subsequent allocation policy to service providers should allow for a minimum of 2
> years worth of usage based on historical or business plan projections. Further, RIRs should implement
> practices that maximise the potential for subsequent allocations to be made contiguous with previous
> allocations."
> >
> > Also, in section 10 it is recommended that "Internet Registries should severely limit or eliminate
> [...] PI assignments". There are obviously reasons for the current policies allowing IPv6 PI
> assignments but the potential for significant routing table growth has not been removed, so I wonder
> whether it would make sense to request the RIR communities to review the impact of PI assignment
> policies on the rate of routing table growth on a regular basis.
> 
> 

I think there may be some new developments you may want to
consider before casting allocation policies in stone. Fred
mentioned ILNP, but there is also the Internet Routing
Overlay Network (IRON - 'draft-templin-iron') which we
are currently progressing through the publication process.

IRON expects that there will be (at least) two distinct
ranges of IPv6 prefixes: 1) PA prefixes which are delegated
to ISPs, and 2) PI prefixes which are delegated to small
end user sites.

IRON expects that the (highly-aggregated) PA prefixes will
be represented in the global IPv6 routing system while the
(fine-grained) PI prefixes will be kept out of the routing
system. So, the routing system scaling can be kept to easily
manageable levels while billions of end user networks can
multi-home, traffic engineer, etc. using PI.

How is this done you may ask? Please check the IRON proposal
and let me know when and where you'd like to discuss it.

Thanks - Fred

---

From: Tony Li <[email-masked]>
Date: Fri, 23 Jul 2010 16:38:44 -0700

Hi Fred,

> consider before casting allocation policies in stone.

Policies never get cast in stone.  They only last until someone comes up with a reason to revise the policy.  ;-)

Further, what we're proposing is one change in allocation policies.

> and let me know when and where you'd like to discuss it.

I don't believe that this list is the appropriate venue and it's certainly not the discussion that we are hoping to spark with this draft.

Tony

---

From: Tony Li <[email-masked]>
Date: Fri, 23 Jul 2010 16:31:09 -0700

Hi Fred,

Well, as mentioned in the draft, there are many factors that influence prefix growth and we do not claim to have a definitive and predictive model of what that growth will be.

It's possible that growth will turn out to match v4 growth, but to do so probably requires that we shift address allocation policies to at least match what's done with CIDR for IPv4.  If we don't progress at least that much, then it's not unreasonable to expect that we will end up with PI advertisements for each possible site (for an arbitrarily small definition of site) for IPv6.  That could grow to be very, very, very large.

Our job is to establish policies, technologies, etc. that ensure that the routing subsystem for the Internet scales.

Regards,
Tony

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 26 Jul 2010 09:10:44 -0700

Tony,
 
> are hoping to spark with this draft.

OK. But, Fred said "ILNP etc" without reproach so it
seemed prudent to mention IRON as included in the "etc". 

Fred