[Apwg-ipv6-papi] hello

[Sonderegger Olaf ABRAXAS INFORMATIK AG]

Hi,

i wasn't able to read anything, and to introduce myself.

But, my Google account is: os at osoz.ch

Olaf

-----Original Message-----
From: apwg-ipv6-papi-bounces at ripe.net [mailto:apwg-ipv6-papi-bounces at ripe.net] On Behalf Of Gert Doering
Sent: Mittwoch, 3. Juli 2013 16:41
To: Elvis Velea
Cc: apwg-ipv6-papi at ripe.net
Subject: Re: [Apwg-ipv6-papi] hello

Hi,

just a few words (thanks, btw, for the introductions :-) - I'm impressed!)

On Tue, Jul 02, 2013 at 07:26:02PM +0200, Elvis Velea wrote:
> I would say that I have quite some experience with the limitations of 
> the current IPv6 policy and have a few ideas on how we can make this 
> policy proposal work. I have almost 0 experience with the practical 
> usage of IPv6 and how it is actually implemented in networks, I hope 
> to learn a bit more from you guys in the process of writing this 
> policy proposal.
> 
> The goal here is, as far as I understand, to unify the IPv6 flavors 
> and have one single policy for all the IPv6 space.

Yes.  The initial reasoning was discussions with end users "what sort of space should I ask for?" and they fully don't understand the difference between PA and PI, which are quite logical for "us at the RIPE NCC level".

So my initial goal was:

  - unify PA and PI into "address blocks"

it's not as simple, though, as the existing differences (that have a reason :) ) will come back as "special clauses".  Like, for example, anycast IPv6 address blocks - they are "just addresses" but come from a specific address range earmarked as "anycast", so people can look at the prefix and see "ah, I should pay more close attention to these in my routing" (for example).  And "PI" comes from yet another block, so people know "this is the only range where /48s are given out from the NCC"...

So for all the caveats, take a look at the concept paper :-)


> My goal is to have a policy proposal which is simple, clear and easy 
> to follow by both the LIRs and the RIPE NCC.

Full ACK.


> @Gert or Emilio: will you create/share the google document or should 
> we create one and start working on it?
> The google account that I will use for this document is elvis at velea.eu 
> so you can share it with me if you will create the document.

I'm gdoering at gmail.com, feel free to create and share.

> Regarding who does what, I understand that:
> - Emilio will be answering the formal questions and help with the 
> guidance in the PDP process

ACK.

> - Sander and Gert will be reviewing the editorial work

ACK.

> - it's up to the three of us (me, Daniel and Olaf) to actually write 
> the document. I offer myself to start writing the policy proposal 
> document and hope that Olaf and Daniel will help with their ideas and 
> technical knowledge.

That is what I was hoping for, indeed :-)

> A few things that come from my experience and I think we should address are:
> 
> 1. do you think that the community will agree with the concept of the 
> RIPE NCC allocating blocks of address space to end-users via the LIR?
> (allocations via the sponsoring LIR concept)

This is what we have today, and what seems to work out quite well - my original idea was to keep that, to make the whole thing low-effort (relatively).

> - do we still want to have the Sponsoring LIR concept in the new 
> policy or should we keep it simple: RIPE NCC allocates to LIR, LIR 
> assigns or sub-allocates to it's customers? in the latter case, if the 
> customer moves to an other LIR, can the assignment/allocation move to 
> the new LIR (and thus have a possible problem with de-aggregation)?

This is one of the tricky bits - there's two ways a customer of a LIR can get space ("as of today")

 RIPE NCC -> LIR /32     -> customer /48 (A)
 RIPE NCC -> LIR sponsor -> customer /48 (B)

and I think we need to keep that in place - so it needs to be very well documented that the "model A" is

 - an entity planning to assign prefixes to end users gets a /29.../32
   from the RIPE NCC, and uses that to distribute /48.../64 to end users.
   Adresses given to end users from the aggregate prefix are not portable
   outside the aggregate, unless special agreements with the aggregate
   holder are made.  (We can't really "forbid" it, as that would not match
   reality, but having a default-deny in here should be good enough)

and "model B" is:

 - an entity needing fully portable address space without the wish to 
   distribute /48.../64 to third parties can get an independent /48 
   for each "end site" (we could define this or leave it as it is - that
   term is coming from the IETF side).  They will receive a dedicated block
   of addresses which is not technically tied to the LIR that facilitated
   the request, just contractually, and can be moved both network-wise and
   contract-wise to other point-of-contacts.


So I don't want so much to change the possible options but to change the "special rules" surrounding "blue" and "green" IPv6 addresses.


> 2. Currently, if you want to start using IPv6 you have a few options:
> 
> a. if you are an LIR - it's simple, request your /32 - /29 from the 
> RIPE NCC and start using it

ACK.

> b. if you are not an LIR, you have a few options:
> i. request the /48 PI via a Sponsoring LIR and you only qualify for 
> more than a /48 if you have more than one end-site/network OR if you 
> can justify the usage of more than 65K subnets ii. request a 
> sub-allocation from an LIR (ALLOCATED-BY-LIR) from which you can 
> assign address space to your network or to your customers iii. if a 
> /48 is enough for your business and you want to offer any kind of 
> services to your end-users, you have to lie to the RIPE NCC, receive 
> the /48 and start assigning from it, thus making sub-assignments and 
> violating the policy.

ACK, and "iii" is actually what I want to kick out at this time, as this is not really useful ("encourage lying or use of a /32").


One of the problems with the current policy documents for IPv*4* is that it intermixes "RIPE NCC -> LIR" and "LIR -> end users" address space delegation.  

Maybe there should be clearly distributed sections or even documents:

 - *policy*: how to get space from the RIPE NCC (who, why, how)
 - *policy*: what is the reciever of a block from the RIPE NCC permitted
             to do with it (= assignment of /48.../64 without questions,
             get approval for bigger.  Also, do sub-allocations if needed)
 - *guidance*: "if I need address space for <x>, what options do I have?"
    (<x> being "for my ISP business", "for my SME company with BGP routing",
     "for my home network", add a few more typical cases)


> 3. the current major problems of the policy, as I see them are:
> 
> - I don't think we have a workable definition of an end-site, the 
> current definition is a start but I think we could make it clearer, simpler.

"end-site" comes from the IETF, which also doesn't give useful guidance...

But yes, the questions "under which conditions is *this* 1-end-site or 2-end-sites?  what can I assign?" is coming up quite often...

> - currently, an organisation which offers services to it's customers 
> has to become an LIR if they want to make assignments - otherwise, if 
> they want to be independent from the LIR they can request a /48 IPv6 
> PI (if a
> /48 is large enough for them and their customers) and hope they will 
> never get caught violating the policy.

Out with this :-)

> - LIRs do not really like sub-allocating parts of their allocations if 
> they have plans to grow their business. In IPv4 quite a few LIRs have 
> made a business out of IP address assignment policies. In IPv6 I do 
> not see this business model taking off yet. The LIRs will be limited 
> by the HD-ratio when they will need to request an additional 
> allocation. It's difficult for an LIR to demonstrate the usage higher 
> than the HD-ratio when some(most) of the space is sub-allocated to 
> customers

It might still make sense to give them the option.  Like, "we know we're never going to use up our /29, but we have 6 different business units which all will never fill up a /32, so we sub-allocate /32s to all of them, and never have to think about it again".  Those who expect growth will not use it, but there are cases where it makes sense...

> - the efficiency measurement unit is a /56 while the LIRs are allowed 
> to assign up to a /48 with no questions asked

Yeah.  This is confusing, but actually it's well-defined "if a /48 is assigned it counts as 256 /56s" (was discussed at one of the RIPE meetings and on the mailing list).  But let's see whether we can come up with different criteria to decide

 - I need a larger initial block than a /29
 - "my block is full"

> - as far as I know, current practice on route filtering is being done 
> at the /48 level. What if ISPs will start following the RIPE Routing 
> recommendations and filter based on the allocation size? In that case, 
> the customers of the LIR that will want to multihome or move to an 
> other LIR will find their prefixes filtered out from the routing table 
> and/or will have to renumber.

"Model B" :-) - and yes, that's to be expected.  Either it's your space, or it's your ISP's space, and then you can't expect it to have full BGP visibility (but it won't do much harm as the aggregate should still be visible).

> - most of the organisations in the RIPE NCC service region still think 
> conservatively when they want to assign address space to 
> infrastructure/customers. I've seen engineers thinking that a /64 is 
> already too large for a customer. The end-user of an ISP or hosting 
> provider in some of the current setups receives a /64 because the 
> engineers do not see the need for multiple subnets for someone's home 
> connection or hosted device.

Guidance document, and policy document "how do give addresses to end users".


> We should ask the LIRs (and their customers) in this policy to:
> - use a /64 only where a single network/subnet is anticipated for the 
> end-site (already part of the current policy) - ie: only to connect 
> the end-site/customer/equipment to the LIR's network/internet
> - use at least a /60 - /56 (?) or larger where the end-site is a 
> customer or would need to use more than one subnet
> - keep the /56 efficiency measurement unit, when an LIR needs to 
> assign more than a /56 to an end-site, it should collect internally 
> some kind of data that justifies the usage of more than a /56

ACK

> - introduce the AW - the LIR should be able to assign up to a /48 with 
> no questions asked (offcourse, the LIR should receive a justification 
> why a /48 is needed for the end-site).

No.  A /48 per end-site can be given out without justification if the LIR thinks it is a good idea.  This is what we have today, and we should not make the new policy more restrictive, like by requiring justification.

Larger-than-/48 is rare enough, still, that I don't think we should reintroduce the complexities of AW management - how many requests have you seen at the NCC asking for end user assignments bigger than a /48?

> - limiting the size of the sub-allocation should also be an idea, an 
> LIR could sub-allocate from their allocation up to a /40 (?) without 
> having to send a request to the RIPE NCC. Anything above the /40 (?) 
> could be approved by the RIPE NCC's IPRAs after an evaluation.

What do we gain by adding restrictions?


[..]
> To sum up, I see two possible models:
[..]
> 2. the RIPE NCC allocates&assigns address space to both the LIR and 
> the end-user (via the sponsoring LIR scheme).

This is what I had in mind, as explained above.  Don't change too many things at the same time, and this general setup seems to work sufficiently well.

If you look at the concept paper again, this brings up new possibilities, namely "multiple ISPs requesting a /32 through a sponsoring LIR", which we can't really prevent if we really want to remove the PA/PI distinction
- if it's just addresses, we need to be ready to give out multiple "large blocks" and "small blocks" *via* the same LIR...  one of the receivers could then be "the LIR itself", but in theory, a LIR could exist that only does "sponsoring LIR stuff", handling /32s for the ISPs in the neighbourhood...


> The end-user, in this case, should be able to use an allocation and be 
> able to make assignments to it's end-sites/customers.
> The Sponsoring LIR should be responsible for making sure that it's 
> customers register the assignments correctly and follow the policy.

ACK.

> In this case we would have several flavors of statuses in the RIPE Database:
> - ALLOCATED-BY-RIR (allocation made by the RIPE NCC)
> - ALLOCATED-BY-LIR (allocation made by the LIR)
> - ALLOCATED-VIA-LIR (allocation made by the RIPE NCC to customer of 
> LIR)
> - AGGREGATED (by the LIR or customer)
> - ASSIGNED (by the LIR or customer)
> - ASSIGNED-BY-RIR (by the RIPE NCC)

What would be ASSIGNED-BY-RIR?  But besides that, yes.  The status: values actually are an interesting can of worms :-)

> My personal opinion is that model 2 would be ideal, however, let's 
> talk and see what you all think.

All for it, see above.

> Enough for today, sorry for the long e-mail :-)

Thanks to get this started (also thanks to Daniel, but answering once should be fine).

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