Subject: [v6ops] Fwd: I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt

From: joel jaeggli <[email-masked]>
Date: Thu, 24 Jan 2013 18:46:51 -0800

Fyi, I would call the attention of the wg to this new draft.

Thanks
joel

-------- Original Message --------
Subject: 	I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt
Date: 	Thu, 24 Jan 2013 18:42:20 -0800
From: 	[email-masked]
Reply-To: 	[email-masked]
To: 	[email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : A mechanism to allocate IPv6 blocks for BGP networks based on the networks AS Number
	Author(s)       : Martin J. Levy
                           Matthew Pounsett
	Filename        : draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt
	Pages           : 7
	Date            : 2013-01-24

Abstract:
    This document provides a methodology for automatically allocating
    IPv6 [RFC2460] address blocks for networks that run BGP [RFC4271] and
    are either single-homed or multi-homed [BARBER2011].  The automatic
    allocation is taken from a specific /16 block assigned by IANA for
    this purpose.

    Networks that require more than this single /48 can still request
    additional allocations via the existing RIR process.  Networks are
    not forced to use this allocation and can ignore this completely.
    Availability of the /48 assignment via this mechanism does not change
    existing mechanisms for obtaining IPv6 assignments through the
    existing RIR (Regional Internet Registry) or LIR (Local Internet
    Registry) mechanisms.

    There is an implicit assumption that it's a good thing to promote
    networks to enable IPv6 with a near-zero effort.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-mlevy-v6ops-auto-v6-allocation-per-asn

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-mlevy-v6ops-auto-v6-allocation-per-asn-00

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Randy Bush <[email-masked]>
Date: Fri, 25 Jan 2013 12:52:56 +0900

> A mechanism to allocate IPv6 blocks for BGP networks based on the networks AS Number

i advocate the wg adopting this

this does not imply that i support it or not.  only that i think that
this wg is the proper place to discuss it.

randy

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 24 Jan 2013 20:55:05 -0800

I believe this I-D would benefit from a clearly articulated problem
statement.
Afaik, acquiring an ipv6 prefix is not a problem.

Sent from ipv6-only Android

---

From: Sander Steffann <[email-masked]>
Date: Fri, 25 Jan 2013 08:22:32 +0100

Hi WG,

> this wg is the proper place to discuss it.

+1
Sander

---

From: Simon Perreault <[email-masked]>
Date: Fri, 25 Jan 2013 10:21:09 +0100

Le 2013-01-25 05:55, Cameron Byrne a écrit :
> statement. Afaik, acquiring an ipv6 prefix is not a problem.

If I understand correctly, the problem statement would look something
like this:

"ASes that do not care or know about IPv6 will not request IPv6 space.
This is sub-optimal for the promotion and adoption of IPv6."

Discuss.

Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Jan 2013 10:17:27 +0000

> This is sub-optimal for the promotion and adoption of IPv6."

That argument seems irrelevant - people who don't deploy IPv6
still won't deploy it. The new prefix will simply sleep.

I think another way of looking at it is:

"Everybody who bothers to get an AS # automatically gets
an IPv6 PI prefix."

afaik, every IPv6-active AS will already contribute at least one
IPv6 BGP4 announcement. I suspect that this proposal would likely
add zero BGP4 entries in practice; it would just save the RIRs and LIRs
some work in handing out PI prefixes.

This doesn't change my underlying distaste for PI prefixes, but
my first guess is that it would not additionally damage BGP4 scaling.
The damage comes from the number of PI prefixes, not from the bit
pattern in the prefixes.

   Brian

---

From: Gert Doering <[email-masked]>
Date: Fri, 25 Jan 2013 13:07:34 +0100

Hi,

> This is sub-optimal for the promotion and adoption of IPv6."

And having a mechanism for "if you care and know about, you can auto-assign
an IPv6 /48 for yourself" will alleviate that?

I'm fine having this in the WG to discuss, but the idea itself I find 
fairly useless - it's not solving the original problem, and it's causing
a bunch of new interesting issues, like "update all tools that build 
routing filters / RPKI to take into account a new class of networks that
is following different rules for route authorization".

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Gert Doering <[email-masked]>
Date: Fri, 25 Jan 2013 13:16:23 +0100

Hi,

> The damage comes from the number of PI prefixes, not from the bit

There is a small risk to it.  If the RIR's PI policies are more strict
than it's AS number policies (which is what we have in RIPE land right
now), people might go for PA space under RIR policies, and not contribute
a global routing entry.  Having this proposal in place would then shift
the question of "who can have an IPv6 PI entry in the global routing?" to
the AS number policy, where it does not belong.

Gert Doering
        -- RIPE APWG chair

---

From: Sander Steffann <[email-masked]>
Date: Fri, 25 Jan 2013 13:36:07 +0100

Hi,

> the AS number policy, where it does not belong.

Doesn't it? Having an AS number means you can participate in the global routing table. So by giving someone an AS number you (implicitly) allow them to advertise prefixes there, right? ;-)

Cheers,
Sander

---

From: Gert Doering <[email-masked]>
Date: Fri, 25 Jan 2013 13:43:31 +0100

Hi,

On Fri, Jan 25, 2013 at 01:36:07PM +0100, Sander Steffann wrote:
> Doesn't it? Having an AS number means you can participate in the
> global routing table. So by giving someone an AS number you
> (implicitly) allow them to advertise prefixes there, right? ;-)

Do I?  I give them a unique identifier that they might need for something,
like private peerings that still should have an unique identifier, building
an internal confederation (where multiple ASes are externally only visible
behind an aggregate), etc.

Gert Doering
        -- NetMaster

---

From: Sander Steffann <[email-masked]>
Date: Fri, 25 Jan 2013 13:49:50 +0100

Hi,

> behind an aggregate), etc.

It would be interesting to see how many AS numbers that are given out by the RIRs are visible in the global routing table... If almost all them them are visible then for practical purposes your use-cases don't make a noticeable difference.

The other areas like RPKI and reverse DNS are a bigger problem I think...

Cheers,
Sander

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 25 Jan 2013 13:51:25 +0000

On 25/01/2013 12:07, Gert Doering wrote:
> fairly useless - it's not solving the original problem

what problem?  It doesn't actually articulate what problem it's trying to
solve.

Nick

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Jan 2013 14:54:44 +0000

> It would be interesting to see how many AS numbers that are given out by the RIRs are visible in the global routing table... If almost all them them are visible then for practical purposes your use…

The answer to that is updated daily on Geoff's site. That's
why I referred to "active" ASs - the ones that are visible in BGP4.

Today for example, he shows 43205 ASs advertising IPv4 routes
and 6660 advertising IPv6 routes, out of 69630 allocated. These
are not big numbers in terms of BGP4 scale.

> The other areas like RPKI and reverse DNS are a bigger problem I think...

Why are they a bigger problem than for PI prefixes?

   Brian

---

From: Gert Doering <[email-masked]>
Date: Fri, 25 Jan 2013 15:58:16 +0100

Hi,

> Why are they a bigger problem than for PI prefixes?

Both assume a hierarchical structure with "someone" at the level above
you to handle delegation.

If it's self-service "I have an AS, here's the formula, that's my network",
who is going to handle RPKI certificates, run the DNS zone and handle
delegations?

Just sayin' - the RIRs have the machinery for this, and this proposal is 
building a parallel address distribution system without any of the 
associated services.

Gert Doering
        -- NetMaster

---

From: Sander Steffann <[email-masked]>
Date: Fri, 25 Jan 2013 15:59:23 +0100

Hi,

> Why are they a bigger problem than for PI prefixes?

They are not a problem for PI prefixes since the RIRs have started to establish a contractual relationship between themselves (as operators of (part of) the RPKI and reverse DNS infrastructure) and the holders of the PI prefixes.

How would that relationship work when every ASN holder can use a IPv6 allocation by default? Who maintains the trust relationship needed for RPKI for example?

- Sander

---

From: John Curran <[email-masked]>
Date: Fri, 25 Jan 2013 10:34:41 -0500

> who is going to handle RPKI certificates, run the DNS zone and handle

From my reading of the draft, it could very easily be the RIRs providing 
those services:

" 8.  RIR support

   It is suggested that RIRs, via their Internet Registry services,
   support these automatic assignments (including but not limited to
   whois and reverse DNS).  The RIRs should provide these services in
   addition to the services already provided for the associated AS
   number. "

> building a parallel address distribution system without any of the 

Perhaps it would be better characterized as "this proposal is building an
alternative ASN-based address distribution system which would require
services similar to those services provided for the existing provider-
independent IPv6 assignment mechanisms"

I also advocate the v6ops working group adopting this ID for discussion.
This does not imply that I support it or not, only that I believe that 
this WG is the proper place to discuss it.

/John

---

From: Simon Perreault <[email-masked]>
Date: Fri, 25 Jan 2013 16:46:06 +0100

> this WG is the proper place to discuss it.

In my understanding, when a WG adopts a document it means that it agrees 
with the general idea and that it wants to work on the draft with the 
goal of publishing it as an RFC.

Deciding whether it's a good idea happens *before* adoption. Like, now.

Simon

---

From: Doug Barton <[email-masked]>
Date: Fri, 25 Jan 2013 07:56:38 -0800

> This is sub-optimal for the promotion and adoption of IPv6."

That's not a problem we can solve with an RFC.

Automatically allocating an IPv6 prefix is a bad idea on its face.

This draft should not be adopted by the group, and should not progress.

hth,

Doug

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Fri, 25 Jan 2013 17:16:06 +0100

Hello,

We are looking for comments on our latest draft RFC version of SSAS. Any and
all comments would be greatly appreciated as we are trying to improve it as
much as possible. 
Thanks in advance. 

http://tools.ietf.org/html/draft-rafiee-6man-ssas-01

Hosnieh

---

From: "George, Wes" <[email-masked]>
Date: Fri, 25 Jan 2013 15:02:15 -0500

> This draft should not be adopted by the group, and should not progress.

[WEG] +1

I thought I remembered this idea being batted around in one or more RIR policy discussions, but I don't know if anything ever came of it (in terms of a formal policy proposal that was subsequently shot down or approved) and a quick search didn't really turn up anything.

I'm opposed to this proposal because it has the potential to further perpetuate routing table bloat by encouraging PI space use in places where it's not strictly necessary, and I do not believe that the adoption of IPv6 is in any way hampered by the current RIR allocation rules. If the authors believe that there is a barrier to IPv6 entry in one or more RIRs' allocation policies, the right place to solve that problem is within the RIR policy development process.
I'm willing to be convinced otherwise, but the draft needs to do a much better job of explaining how this fixes anything and why it needs to be addressed by IETF and not in the RIRs.

As others have stated, I agree that v6ops is probably the right WG for discussion of this draft. *However* I do not believe that's the right test for adoption. I don't support adopting it as a WG item without consensus that the WG agrees with the basic problem statement and solution and just needs to refine it.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Sander Steffann <[email-masked]>
Date: Fri, 25 Jan 2013 23:35:48 +0100

Hi Wes,

>> This draft should not be adopted by the group, and should not progress.

Well, to be honest I think it's a bad idea for several reasons. At least in the RIPE region the policy for IPv6 PI space is such a low barrier that I can't imagine any organisation who is serious about IPv6 not qualifying... So I really don't see the need (to put it bluntly) to bypass the RIRs here.

> I thought I remembered this idea being batted around in one or more RIR policy discussions, but I don't know if anything ever came of it (in terms of a formal policy proposal that was subsequently…

Probably this one: http://www.ripe.net/ripe/policies/proposals/2008-01. The conclusion was that those who want IPv6 can get it easily from the RIR, and those that don't want IPv6 won't use any address space you 'force' on them.

> I'm opposed to this proposal because it has the potential to further perpetuate routing table bloat by encouraging PI space use in places where it's not strictly necessary, and I do not believe that the adoption of IPv6 is in any way hampered by the current RIR allocation rules.

+1

> If the authors believe that there is a barrier to IPv6 entry in one or more RIRs' allocation policies, the right place to solve that problem is within the RIR policy development process.

Yes, and I would welcome any discussion if someone thinks we're doing it wrong in RIPE land! Usually people tell me that in the RIPE region it is incredibly easy to get IPv6 PI space. I can't speak for other regions obviously.

+1

> As others have stated, I agree that v6ops is probably the right WG for discussion of this draft. *However* I do not believe that's the right test for adoption. I don't support adopting it as a WG i…

I think at least having some discussion in this WG is good, even if it only is to confirm that it doesn't belong here. The only reason for a draft like this would be if the RIR policies are bad. As one of the address policy WG chairs of the RIPE region I wouldn't mind this discussion, hopefully with the conclusion that this draft isn't necessary :-)

Thanks,
Sander

---

From: Randy Bush <[email-masked]>
Date: Sat, 26 Jan 2013 13:22:03 +0900

my first take, tactless as usual

the goal is avoiding rir bureaucracy and cost.  this is not necessarily
a bad thing.

the result will be yacaa<tm>, yet another class of address allocations.
every time we have done this, it has been convenient until it becomes
painful.  look at the effort in the ripe region reconciling pi space,
legacy space, ....

some of the immediate consequences have been pointed out.  who delegates
the dns and how do they know who the heck you are and if you have the
right to that asn/space?  abuse contact, rpki, ...

but i do see sense in the argument that the cost and bureaucracy of
dealing with rirs is painful and unnecessarily so.  i just think that,
at least in this case, it would be better though not easier to fix the
root cause of the problem than kludge around it.

randy

---

From: "Ivan Pepelnjak" <[email-masked]>
Date: Sat, 26 Jan 2013 07:49:09 +0100

Could the root cause be that ARIN charges at least $1250 per PI allocation, whereas it costs €50 in RIPEland if you're smart enough to attach yourself to a LIR?

https://www.arin.net/fees/fee_schedule.html
http://www.ripe.net/ripe/docs/ripe-566

In any case, there's a long history of horrible technology kludges created to "solve" layer 8-10 problems ... and they all looked like a great idea once.

Ivan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Randy Bush
> Sent: Saturday, January 26, 2013 5:22 AM
> To: Sander Steffann
> Cc: IETF v6ops list
> Subject: Re: [v6ops] I-D Action: draft-mlevy-v6ops-auto-v6-allocation-per-
> asn-00.txt
> 
> the goal is avoiding rir bureaucracy and cost.  this is not necessarily a
> bad thing.
> 
> dealing with rirs is painful and unnecessarily so.  i just think that, at
> least in this case, it would be better though not easier to fix the root
> cause of the problem than kludge around it.
> 
> randy
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Randy Bush <[email-masked]>
Date: Sat, 26 Jan 2013 16:54:05 +0900

> Could the root cause be that ARIN charges at least $1250 per PI
> allocation, whereas it costs €50 in RIPEland if you're smart enough
> to attach yourself to a LIR?

and you get the pain of dealing with the bureaucracy and arrogance.

> In any case, there's a long history of horrible technology kludges
> created to "solve" layer 8-10 problems ... and they all looked like
> a great idea once.

exactly.  the long term solution is to clean up the rirs.

randy

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 26 Jan 2013 08:46:45 +0000

> I thought I remembered this idea being batted around in one or more RIR policy discussions, but I don't know if anything ever came of it (in terms of a formal policy proposal that was subsequently…

I remember suggesting this idea to Steve Deering in about 1995, before
IPv6 basics had even stabilised, and he explained to me why it was a bad
idea because of the resulting BGP4 bloat. This was at a time when we did
not expect PI prefixes to exist in IPv6, and we seriously hoped to have a
very nicely aggregated IPv6 DFZ. That hope is receding today, so the
argument is less strong than in 1995. All the same, unless there is
factual evidence of operators finding it harder to get an IPv6 prefix
than an AS #, it does seem like unnecessary entropy.

  Brian

---

From: Sander Steffann <[email-masked]>
Date: Sat, 26 Jan 2013 13:43:39 +0100

Hi Randy,

> my first take, tactless as usual

Nah, just a clear an honest answer I think :-)

Thanks,
Sander

---

From: John Curran <[email-masked]>
Date: Sat, 26 Jan 2013 09:54:51 -0500

> https://www.arin.net/fees/fee_schedule.html

Note that in the ARIN region there has been well-received fee schedule consultation 
to add a smaller ISP category (XX-Small, $500/yr, IPv4 /22 or smaller, IPv6 /48 or 
smaller), and there will more information on this in the next month.  It's still not 
$50/year, but it a step in the that direction for provider-independent v6 assignments.

There is a more fundamental underlying question here, which is whether or not an 
organization which has obtained an AS for multihoming should be able to have use 
of an IPv6 block for the same purpose.  There's definitely potential IPv6 routing 
table bloat of order (number of ASNs), but that same order of magnitude potential 
exists if they multihome using their current provider-assigned IPv6 /48 assignments.  
Perhaps the interesting question is whether ISPs would route such ASN-based /48's 
for non-multihomed customers, or push back and requiring multihoming (and/or charge 
to do so...?)  Do ISPs today provide any incentive to use provider-assigned IPv6 
prefixes, or is it simply lack of PI availability which prevents IPv6 routing table
growth?

/John

Disclaimer: My views alone.  This post is composed of 100% post-consumer electrons.

---

From: David Farmer <[email-masked]>
Date: Sat, 26 Jan 2013 11:42:11 -0600

This Draft basically substitutes ASN assignment policy for IPv6 address 
assignment policy or at least makes them equivalent for one /48.  This 
isn't necessarily a bad thing, but it means we need to evaluate the ASN 
assignment policies of the RIR's and the technical basis for those 
policies to properly evaluate the consequences of this Draft.

RFC 1930 provides the most recent technical recommendations for the use 
and assignment of a unique ASN and are more or less the basis of the 
RIRs' ASN assignment policies.  However, RFC 1930 itself assumes an ASN 
is only necessary if there are one or more IP prefixes to be routed with 
a unique routing policy.  It is generally understood that a unique 
routing policy effectively requires multihoming or peering with more 
than one other ASN.

The fact that RFC 1930 seems dependent on a prefix to justify an ASN, 
seems to imply that you already need an IPv4 or IPv6 prefix in order to 
use the IPv6 prefix assigned by this Draft.  If you already have an IPv6 
prefix then the IPv6 prefix assigned by this Draft is unnecessary and 
superfluous.  This leaves IPv4, and if you have already have an IPv4 
prefix the RIR's policies make it trivial to justify getting an IPv6 
prefix, and one RIR has essentially a one click request process at least 
for ISPs.

There is one corner case where this Draft may be useful, depending on 
your point of view;  It would allow Legacy ASN holders to get a /48 of 
IPv6 without having to talk to any RIR.  While this may be beneficial to 
a small few, allocating a /16 of IPv6 space solely for the benefit of 
such a small few seems wasteful of even a plentiful resource like IPv6.

However, if we were to reexamining and update RFC 1930, better defining 
when unique ASNs should be used and allocated, especially making that 
independent of any existing IP prefix; then maybe this Draft would have 
the general applicability and usefulness that would justify the 
allocation of a /16 of IPv6 space for this purpose.  Without such an 
update of RFC 1930, I could not support this draft.

Side Note, the Draft should require; That an IPv6 prefix from this range 
MUST only be originated from the ASN that the IPv6 prefix is assigned 
to.  Furthermore, an ASN MUST NOT originate a IPv6 prefix from this 
range that assigned to another ASN.

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 26 Jan 2013 17:49:22 +0000

On 25/01/2013 12:07, Gert Doering wrote:
> fairly useless

I'm not sure why the WG should adopt this without a clear problem statement.

Nick

---

From: joel jaeggli <[email-masked]>
Date: Sat, 26 Jan 2013 10:22:26 -0800

On 1/26/13 12:46 AM, Brian E Carpenter wrote:
> very nicely aggregated IPv6 DFZ.
There a somewhat naive notion of what constitutes a provider that seems 
to have pervaded that discussion. It should have been obvious (was to me 
at least) when among the first assignments were universities, equipment 
vendors, and large enterprises, that the entities that find  it 
necessary to multihome from their own address space in ipv4 did (and 
would) find it necessary to do so in ipv6. There are some other things 
we were totally wrong about like flow cached forwarding.

The ipv4 routing table doesn't have 440,000 ipv4 routes in it because 
30,000ish ASes find it necessary to advertise a prefix, a big chunk of 
those only advertise  1 prefix in ipv4. It has 440k entries because ISPs 
are fairly obnoxious polluters and enterprises like the one I work for 
find it necessary to go back for additional direct assignments, 
de-aggreate regionally for TE purposes, don't have enough bits in ipv4 
to hierarchically allocate prefixes so they can more easily be 
aggregated. I have to de-aggregate in ipv6 for more or less the same 
reasons except for the don't have enough bits problem, the upshot being 
that I can better aggregate in ipv4 relative to ipv6 .
>   That hope is receding today, so the
Having done this in three different entities over the years (in the arin 
region), getting an AS number, ipv4 prefix assignment, and ipv6 prefix 
assignment was not particularly onerous, prior to the notion of ipv6 
direct assignments, the justification for and entity that was not 
obviously a transit isp was a bit different 12 years ago then it is now...

---

From: joel jaeggli <[email-masked]>
Date: Sat, 26 Jan 2013 13:30:29 -0800

On 1/26/13 10:22 AM, joel jaeggli wrote:
> those only advertise  1 prefix in ipv4. It has 440k entries because 
> ISPs are fairly obnoxious polluters and enterprises like the one I 
> work for find it necessary to go back for additional direct 
> assignments, de-aggreate regionally for TE purposes, don't have enough 
> bits in ipv4 to hierarchically allocate prefixes so they can more 
> easily be aggregated. I have to de-aggregate in ipv6 for more or less 
> the same reasons except for the don't have enough bits problem, the 
> upshot being that I can better aggregate in ipv4 relative to ipv6 .
ipv6 relative to ipv4 I mean.

---

From: Randy Bush <[email-masked]>
Date: Sun, 27 Jan 2013 11:28:22 +0900

> I'm not sure why the WG should adopt this without a clear problem

this wg is clearly the place to discuss this draft.  in fact, we are
discussing it.  

can we please not in the pointless sport of draft torture to get it
properly on the table and in our gunsights?  or stop discussing it.

randy

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 27 Jan 2013 06:56:16 +0100 (CET)

On Sat, 26 Jan 2013, Brian E Carpenter wrote:

> not expect PI prefixes to exist in IPv6, and we seriously hoped to have 
> a very nicely aggregated IPv6 DFZ. That hope is receding today, so the 

I agree with the above statement. Generally, a lot of ASNs will only need 
a single prefix. If this prefix is that single prefix, then I'm fine (this 
replaces PI/PA handed out by a RIR). *BUT*, I don't want a lot of ASNs 
both advertising a /48 out of this draft, *and* addresses from RIR space.

I dislike DFZ slot usage for no good reason. If this draft stated that 
this draft-handled space was ok to use if it was the only space announced 
by this ASN, then I would be fine.

But I agree with Randy Bush, that if this is created to somehow fix a RIR 
problem, then we're fixing it through semi-technical means which is the 
wrong way to fix a perceived RIR problem.

I also dislike the reverse DNS pointer in 9. Who administrates this, the 
RIR in charge of the ASN?

So even though this seems to try to circumvent RIRs, parts of what the 
draft handles is still going to need RIR administration assistance?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 27 Jan 2013 08:15:14 +0000

Joel,

On 26/01/2013 18:22, joel jaeggli wrote:
>>> I thought I remembered this idea being batted around in one or more
>>> RIR policy discussions, but I don't know if anything ever came of it
>>> (in terms of a formal policy proposal that was subsequently shot down
>>> or approved) and a quick search didn't really turn up anything.
> to have pervaded that discussion. 

All I can say was that in 1995, CIDR was quite new, commercial and consumer
use of the Internet was just getting seriously started, and there was serious
hope that IPv6 would remain 100% provider-aggregated. My point was not to
complain that this didn't work out, but to observe that this is not a new
idea by any means.

> It should have been obvious (was to me
> would) find it necessary to do so in ipv6. 

Yes, but that's why some of us have tried very hard to promote multi-prefix
multihoming. However, that's a side issue for the present draft, which
is just another form of PI allocation.

> There are some other things

That's the data point we need for this discussion. If there is no particular
difficulty about getting a PI prefix *when it's justified* we don't need
a new method.

    Brian

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 27 Jan 2013 16:20:44 +0000

> properly on the table and in our gunsights?  or stop discussing it.

ok, whatevs.

Without a clear statement of purpose, I'm left guessing that the purpose of
this draft is probably a combination of an attempt to bypass the RIRs, to
make ipv6 more easily available to end-users and to generally drop costs.
There may also be an element of protest about RIR resource management,
policy management and all that.  These are all guesses, btw.  The rationale
needs to be stated clearly in the document.

The problem as I see it is that this draft attempts to replace one system
which is arguably broken at layers 9 and above with another system which is
broken at layer 3 and above.

in no particular order, specific technical problems with the draft include:

- this looks like a rehash of rfc1897 with extra knobs.  I used a 5f00::/8
prefix at the time and remember a disappointing lack of general management
associated with it.

- renumbering ASNs creates a requirement to renumber the network
assignment.  This is a major pain.

- the draft creates a requirement for Internet-with-a-big-I DFZ routers to
filter off an entire extra class of prefixes corresponding to the private
ASN allocation ranges.

- the whois mechanism is poorly specified.

- the draft requests that the RIRs agree to this.  I'm not going to make
any statement about whether they would intend to or not, just that the IETF
doesn't have any particular authority to demand this, although they can
request it as a favour.  But what happens if a RIR refuses to comply due to
top-down or bottom up policy mandate, or simply because the bottom up
process couldn't come to a conclusion?

- as a separate issue, there is no existing mechanism to tie these prefixes
into the IRRDBs (which are technically separate to the RIR assignment
databases).  This will have operational implications.

- as an aside to this, there are two mechanisms for handling IRRDB
registration: good faith (e.g. RADB, ALTDB) and grandfathered (RIPE DB,
ARIN RR DB, etc).  While there wouldn't be any particular reason that you
couldn't register these prefixes in a good faith database, you couldn't
register them in a grandfathered IRRDB without buy-in from the RIRs.  This
has serious implications for the IRRDB data trust model.

- reverse DNS hard-codes IP addresses.  I really don't like this on a
matter of principal.  It also explicitly prevents ipv4 dns servers from
being used.

- RPKI will not work without full support from the RIRs.

- the proposal may drag the IETF into resource assignment arguments.

- there is no indication of whether a prefix of this form must or should be
announced from its corresponding ASN

- no statement on what happens if someone relinquishes their ASN but
decides hey they don't want to bother renumbering.

- it ties ipv6 assignment to ASN assignment.  These two things are separate
and should probably be kept separate.

- it will create ipv6 dfz bloat

some nits relevant to the draft:

- it should probably reference rfc1897 as a precedent

- this line is incorrect:
       |        AS29001 |               7149 | NNNN:0000:0001::/48 |

  it should be:
       |        AS29001 |               7149 | NNNN:0002:9001::/48 |

If this is an attempt to provide easy access to IPv6 addresses to anyone
with an ASN, I can understand the intention but think the approach is
broken.  If it's an attempt to bypass the RIRs, it's also broken on
multiple accounts - namely that it requires substantial RIR buy-in in order
to work, but doesn't provide the RIRs with the resources to support those
services.  If there is a problem with RIRs, then perhaps that ought to be
taken up by the RIR memberships so that they can fix their own problems
from the bottom-up.

Either way, I don't think that this draft solves any problems that I can
see in such a way that even worse problems aren't created as a by-product.
 This is why I suggested that the authors need to specify their problem
statement.  Because of this I don't think that it ought to be adopted as a
WG document.

Nick

---

From: Randy Bush <[email-masked]>
Date: Mon, 28 Jan 2013 03:00:45 +0900

> The problem as I see it is that this draft attempts to replace one
> system which is arguably broken at layers 9 and above with another
> system which is broken at layer 3 and above.

pretty much agree, except i would s/9/8/ (apnic and arin being worse
than ripe)

> specific technical problems with the draft include:

yep, fair arguments to either get these points addressed by the author
or to not advance the draft.

> - the draft requests that the RIRs agree to this.

probably takes only one to do the whois, rdns, irr, certs, ...  but i
suspect none will touch it with a 3.048m pole.

randy

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 27 Jan 2013 18:42:15 +0000

> suspect none will touch it with a 3.048m pole.

it will take buy-in from all of them due to the way that ASNs are allocated
piecemeal from iana.  mess level: severe.

Nick

---

From: John Curran <[email-masked]>
Date: Sun, 27 Jan 2013 15:16:01 -0500

On Jan 27, 2013, at 11:20 AM, Nick Hilliard <[email-masked]> wrote:

> ...

If the Internet technical community feels that the world has changed (or 
is now sufficiently well understood?) such that autonomous systems should 
be able to automatically have provider-independent IPv6 prefixes, then 
that is worth clearly stating.  The Internet technical community consists
of lots of folks (including protocol and system folks, academics, operators,
etc.); some participate in IETF and some in the Regional registry meetings.  
There are actually agreements that are applicable to how Internet addresses
are managed (e.g. parts of RFC 2860), but in general, the status quo prevails 
unless/until the Internet community has reached some overall consensus on 
some need for change.

I don't see any reason for the IETF not to consider the question posed by the 
draft, as it is architectural in nature (effectively being "would Internet route 
aggregation be significantly harmed if IPv6 included provider-independent prefixes 
for all autonomous systems?"), but am also realistic that any such finding would 
also need to be considered in those participating in the Regional registry 
communities if we're to achieve overall consensus.

I have yet to see a case where the IETF and RIR processes have not converged 
on an outcome, and while there always is a potential for such disagreement, 
that is usually indicative that _more_ discussion of merits and concerns of 
a topic is needed, not less.

FYI,
/John

Disclaimer: My views alone, based on personal experience with RIR and IETF 
            processes; YMMV.

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Mon, 28 Jan 2013 10:02:57 +0100

+1

Jan

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 28 Jan 2013 20:03:44 -0800

> exactly.  the long term solution is to clean up the rirs.

What exactly would a clean up of the RIR entail?

In any event, let us have mercy on the folks who would benefit from
this /48 per ASN.

I see no major downside and a substantial upside to making this I-D a WG draft.

CB

---

From: Doug Barton <[email-masked]>
Date: Mon, 28 Jan 2013 22:28:25 -0600

> What exactly would a clean up of the RIR entail?

Outside the scope of of this WG, IMO. There are various and sundry
improvements that could be made in all 5, but ...

> In any event, let us have mercy on the folks who would benefit from

Before this would even be a viable candidate, it is necessary to define
what the current barriers are that prevent organizations who already
have, or will be assigned, an ASN from also getting PI space now. To the
best of my knowledge not only are there no meaningful barriers now, all
of the RIR policies that I'm aware of (and while my knowledge isn't
perfect, I do try to stay on top of these things) already _encourage_
organizations to get IPv6 allocations.

> I see no major downside and a substantial upside to making this I-D a WG draft.

Have you actually followed the discussion on the list to date? There
have been numerous downsides discussed, and no upsides defined yet.

Doug

---

From: Randy Bush <[email-masked]>
Date: Tue, 29 Jan 2013 13:44:39 +0900

> What exactly would a clean up of the RIR entail?

well, to start, teaching them  words such as 'bookkeeper' 'customer' ...

> In any event, let us have mercy on the folks who would benefit from

who are they?

> I see no major downside and a substantial upside to making this I-D a

hey, i get credit for being the first to advocate adoption.  just don't
take this to mean i think the draft should progress further.  but i am
listening.

randy

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 28 Jan 2013 21:17:33 -0800

> organizations to get IPv6 allocations.

I do not believe ARIN has done much to push v6. They showed up for carrier
transition space and have done drip-feed ipv4 allocation policy to make the
transition last as long as possible and ensuring the future of CGN.

Let's just say I do not feel well served by my RIR. That has been my
feeling for 13 years. I have tried to be involved in RIR policy,  but it
has been a real stretch of my patience.

> have been numerous downsides discussed, and no upsides defined yet.

TL; DR

I stopped dreaming that ipv6 was going to be strongly aggregated at least 5
years ago.  Many networks dont use rir whois / rdns / ...

Upside is that I dont have to disclose anything to an rir who has no
business / understanding in how my network runs.

If LISP can get a /16, so can this.

CB

---

From: Doug Barton <[email-masked]>
Date: Tue, 29 Jan 2013 00:08:43 -0600

On 01/28/2013 11:17 PM, Cameron Byrne wrote:
> On Jan 28, 2013 8:28 PM, "Doug Barton" <[email-masked]
> <mailto:[email-masked]>> wrote:
>>
> I do not believe ARIN has done much to push v6.

Then to put it bluntly, you haven't been paying attention. I have
"issues" with some of what ARIN does, and/or how they do it, but they
have been going out of their way to promote v6 adoption for years now,
especially during the "promotional period" when they were practically
giving it away. I don't have all the details easily to hand atm, and
frankly don't feel compelled to dig them up for you.

On the contrary, the burden is on you (and other proponents) to
demonstrate actual, concrete barriers that the RIRs have placed in front
of v6 allocation, and why this draft would solve them.

> They showed up for
> carrier transition space and have done drip-feed ipv4 allocation policy
> to make the transition last as long as possible and ensuring the future
> of CGN.

Their support of "the CGN prefix" is one of the things they have done
that I don't like, for sure. I do think that carefully scrutinizing all
applications at this point is reasonable, but in my experience this
isn't really a new policy.

> has been a real stretch of my patience.

C'est la vie. No one said it would be easy. Personally I have chosen not
to tilt at these particular windmills because I have other things to
fill my days with. You have to decide how important it is to you.

> I stopped dreaming that ipv6 was going to be strongly aggregated at
> least 5 years ago.  Many networks dont use rir whois / rdns / ...
> 

So what you want is an end-run around the RIRs? The IETF is not going to
approve that (nor should they). They are equally unlikely (nee unable)
to dictate to the RIRs that they allocate space to people outside of
their usual policies/procedures/fees/etc.

In short, completely aside from all the reasons this is a bad idea, it
cannot, and should not happen.

Can we move on now?

Doug

---

From: Randy Bush <[email-masked]>
Date: Tue, 29 Jan 2013 15:17:47 +0900

> If LISP can get a /16, so can this.

it's not the space.  if that was all of it, i would be a very strong
supporter.

it's the whois, reverse dns, irr, rpki, ...  and, while the receiver may
or not want those services, as an op who gets their packets, i want them
to have them.

and, while the rir cartel is pretty aggressive at layers nine and ten,
they're damaged and stingy at eight and below.  so who provides those
services?

randy

---

From: Gert Doering <[email-masked]>
Date: Tue, 29 Jan 2013 09:30:38 +0100

Hi,

> In any event, let us have mercy on the folks who would benefit from

Who exactly would that be?

(I see this through RIPE land glasses, so there might well be some good
reasons in the ARIN region)

Gert Doering
        -- NetMaster

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 29 Jan 2013 06:36:04 -0800

> Then to put it bluntly, you haven't been paying attention. I have

Far out.

> On the contrary, the burden is on you (and other proponents) to

Why is the burden on me? Because of inertia?

---

From: Sander Steffann <[email-masked]>
Date: Tue, 29 Jan 2013 14:47:26 +0000

Hi,

> Why is the burden on me? Because of inertia?

I think the burden is on the people who want to push this policy forward. I don't think it's unreasonable to let those who want to change something explain/justify why they want the change. If it's not possible to give good reasons for a proposal then why propose it in the first place?

Thanks,
Sander

---

From: Randy Bush <[email-masked]>
Date: Wed, 30 Jan 2013 00:25:22 +0900

[ attribution intentionally removed ]

< pontification >

> I think the burden is on the people who want to push this policy
> forward.

we all share the burden, that of making the best engineering decision
we can.  can we please stick to the engineering part of the discussion?
despite 60+ messages in the thread, i have not learned anything new on
this one for nigh a day.  and yes, this message is as guilty as most.

randy

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 29 Jan 2013 09:40:20 +0100

> Who exactly would that be?

That one organization who will be hooking up a few more BGP tunnels and
then claiming they are the number one global transit provider as they
have so many ASNs connected.

At least, that is the only one who will 'benefit' out of this it
seems... everybody else can just go to their RIR and get a prefix.
The ISPs that do not care will not care either.

Greets,
 Jeroen
   ~~ just shove a little bit of traffic over it, just shove a ... ;)