Jordi, On Wed, May 02, 2007 at 04:23:16PM +0100, JORDI PALET MARTINEZ wrote:

No, it is a different thing (local/RFC4193 vs. central).

This draft (ula-central-01) is already being updated.

I really looks like RFC 4193 is ula-central-01 with the central registry taken out. I mention this because the central registry must have been taken out for a reason, and I think it would be easier if we knew those reasons rather than having to guess at them.

The policy proposes to act as one of the central (consider one of the draft options "central but distributed in several entities", take that as one or several RIRs) registries.

I need to clarify that this is something that has been consulted for months with the NRO and the NRO answer was: "fine, but go to each region with a policy proposal, otherwise we can't do it".

Right, so the idea is that the NRO will run a registry, and that the RIRs will act as registrars for this. Hopefully the policies will be similar in each region. And the proposal that these addresses will be issued directly by the RIPE NCC to end users? I think this is interesting, but if that is the idea, then the whole structure (NRO->RIR->end users) seems really complicated. There are about 1 trillion of these /48's. I think a much better idea would be for the NRO to set up a web page where you type in your credit card number and for 5 euros (or 10 or 20 or whatever) you get a /48. (Not an original idea of mine, but I can't remember who suggested it to me.) If you don't want to spend the 5 euros (or 10 or 20 or whatever), you can always use a random /48 from RFC 4193. If the NRO demands that this be a policy action within each region, there's no special reason the NRO has to be involved, is there? Anyone with a server can run this. -- Shane

This draft (ula-central-01) is already being updated.

The policy proposes to act as one of the central (consider one of the draft options "central but distributed in several entities", take that as one or several RIRs) registries.

If it is a draft then these ULA addresses do not exist. If they do not exist, how can an RIR set up a registry for them? Or are you suggesting that the RIRs should overthrow the IETF? --Michael Dillon

Hi, On Thu, May 03, 2007 at 11:41:10AM +0100, michael.dillon@bt.com wrote:

If it is a draft then these ULA addresses do not exist. If they do not exist, how can an RIR set up a registry for them?

Or are you suggesting that the RIRs should overthrow the IETF?

We're working on both ends in parallel, given that the PDP process will usually take quite some time (especially for a global policy). So this is sort of a "if the IETF should make space available for ULAs, will you be happy with this policy?" thing. (And on the other side, the question is "if the RIRs are willing to set up a central registry, would the IETF make available ULAs?" - so we can't just wait for the IETF without having some sort of consensus that the RIR system will do this) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 113403 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

Hi Geoff, I guess it is important to clarify that the authors of the draft are working on a new version. I've not yet seen it, so I'm not sure if it is addressing already any of your points below. Trying to answer your points below, but as a general comment, I think they are operational aspects that the community should rely on the RIRs staff to manage. At least, I personally trust them. There have been many similar examples discussed in other regions of operational issues and once the RIRs are asked about if they want to have a policy, the message is clearly negative: They need freedom to implement things. In this case it is more evident. The implementation can be different if it is taken by one or several RIRs, or by the NRO itself, etc. I'm happy if the result of the implementation is that somebody can get allocated a ULA-central prefix (I don't really care the price, because I understand need to be based on a cost recovery model and to be decided by the board), to be used as for the example in the proposal for infrastructure microallocations, instead of wasting global address space. I also guess that this can be done with a much simple document not detailing so much as the actual ID. This is why I think this "parallel" (RIRs+IETF) process is important, because it may actually help to provide inputs for subsequent versions of the ID. See below, in-line. Regards, Jordi

De: Geoff Huston <gih@apnic.net> Responder a: <address-policy-wg-admin@ripe.net> Fecha: Thu, 03 May 2007 08:20:21 +1000 Para: Shane Kerr <shane@time-travellers.org>, "address-policy-wg@ripe.net" <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] 2007-05 New Policy Proposal (IPv6 ULA-Central)

At 01:03 AM 3/05/2007, Shane Kerr wrote:

...

All,

I think the draft this proposal refers to:

http://tools.ietf.org/html/draft-ietf-ipv6-ula-central-01

Is an early version of what eventually became RFC 4193:

http://tools.ietf.org/html/rfc4193

The RFC does not have any centrally assigned addresses.

I didn't actually follow the discussion in the IETF about this document, so I don't know why the centrally assigned version was removed.

The IETF history of this document was that an original proposal was for two pools of ULA addresses - one a "self-draw" and one "centrally assigned". The draft was split into two drafts, and the draft describing the "self-draw" pool was published as RFC4193 while the IPv6 working group abandoned work on the centrally assigned address pool

...

It's not actually clear to me what the policy proposal is. Does it intend for the RIPE NCC to act as a central registry for all local IPv6 addresses? Does it intend for a special membership category be set up for this?

I posted the following comments and question to the Afrinic policy mailing list in response to this proposal - I suspect that these questions and comments are relevant here as well.

When this was under consideration within the IETF some years back I performed an evaluation of the draft from the perspective of the RIRs as a potential operator of this service. In reading through this proposal these considerations appear to remain relevant today, and it may be useful to consider these issues when considering the operational aspects of provision of such a registry service.

I guess this document was feed into the IPv6 WG. It will be interesting to know the answers provided by the IETF process then.

The evaluation report included the following considerations:

-----------------------------------------------------------------

- the 'nature' of the distribution function for this part of the IPv6 address appears to be an allocation to be undertaken in perpetuity. It is possible to interpret this allocation in terms comparable to some form of 'freehold property' given that the self-allocation via the central registry gives the entity exclusive unqualified right of access without any form of expiration or renewal of the original allocation.

Current RIR allocations of unicast public address space are undertaken under conditions that are broadly consistent with a non- assignable lease.

I think we do that with other special addresses, such as multicast, etc., via direct allocation from IANA. What is the difference ?

It may be that this issue of assignments performed in perpetuity vs fixed period renewable assignments should be a matter of choice by the client as the time of assignment, and that pricing for this address assignment reflect the different cost structure of secure maintenance of assignment records for a fixed period vs costs for this record maintenance to be undertaken in perpetuity.

I don't think the policy proposal precludes doing so. We may need to decide if this should be so clearly defined by the policy or trust the board. I will think the last one, as they policies don't define fees.

- it is unclear whether the privacy of the assignee is intended to absolute or under what circumstances the central registry operator would divulge this information and to whom. It was noted that all information held by the RIR is not covered by any binding privilege. It is the case that such RIR-held information is discoverable by others using legal means under certain circumstances. Open questions include:

Would anyone be able to ask whether a specific prefix was allocated or not?

I don't think we can define an absolute "privacy". Lawful interception is always something under the relevant authority control, so definitively they should be able to ask if prefix "x" belongs to somebody and in that case, whom.

Would a holder be able to 'recover' their prefix from the registry?

I don't see why it can't be feasible. I will say that those are good ideas for the staff implementing it.

Could a holder request the registry to expose their holding to a specific third party?

Same answer as the previous one.

Could the privacy requirement be changed at a later date?

By whom ? Any specific example of why you think this may be required ?

Would any future changes to the privacy requirement (or any other characteristics of these addresses) be a policy matter to be determined within the addressing community, or would any changes to the characteristics of this space remain solely within the purview of the IETF?

I think we should follow the draft, or provide inputs to update it, and this may be one of the issues, but probably an example of why you think this is important could help.

- Permanence of allocation. Should there be a capability for an assignee to voluntarily return an allocation? How can the assignee

I think this could be a nice to have feature, of course.

and the returnee be matched? If the allocation is not public knowledge how can a return be effected? Should these allocations be

Implementing privacy doesn't necessary means that the RIR don't know who owns a prefix, in fact this is required in order to execute the contract as stated in the policy proposal.

permanent or of some fixed term with a periodic renewal option?

I will not really care if the board decides to implement a periodic renewal fee.

- Distribution functions. Should there be some form of 'wholesale' form of bulk access to this registry, to allow, for example, a manufacturer to place pre-paid prefixes into manufactured devices? If not, could this form of use of the central registry services be supported using mechanisms described in the current proposal?

I don't see right now if this could be useful, but if you have a specific example, I guess it could be considered then in the implementation.

- Associated information and pointers. The proposal is silent on reverse DNS for these prefixes. Perhaps the final version of this document could explicitly say that this requires private DNS (two- faced DNS) deployment and that placing these prefixes in the ip6.arpa zone is not to be supported. Or should such reverse DNS delegation be allowed? After all these global IDs are unique and in and of itself putting them in the public DNS is not going to harm the DNS. Of course the random nature of these assignments has the potential to, over time, create an extremely large flat DNS zone. This may have implications in terms of signing the zone with DNSSEC of course. Some guidance the preferred approach of populating the DNS reverse zones would be preferred, if reverse DNS is to be supported for these addresses. If this reverse DNS is to be allowed, does this compromise the private nature of the assignment? The proposal is also silent on WHOIS entries.

It appears that there is an explicit privacy issue where that precludes any inclusion in the WHOIS databases, but an explicit statement to this effect in a final version of this document would be preferred. It is probable that inclusion in the public DNS, whois information and the privacy of these assignments are related matters.

I think the usage I'm perceiving for ULA-central could be made with two-faced DNS, but I may be wrong.

- Routability of these prefixes. The RIRs maintain that they take no position on the routeability of prefixes that they assign. It would appear that this position extends to this central registry managed site local prefix.

Yes, but that's doesn't preclude to have routability statements across many policies. In this proposal we only state what is not the intend of this prefix, and this could be tied in the future to resource certification in the same way as the rest of the prefixes.

- There is no doubt that there would be some effort expended on the part of the RIRs to implement this registry operation. Pricing for the service may need to be determined within the parameters of a cost recovery function for operation of the function distinct from the costs of other RIR functions, and within the parameters of the anticipated costs of secure maintenance of records in perpetuity.

Agree, as stated above, I don't really care about the price for the registration and trust the staff to evaluate the cost and the board to implement the relevant contracts and fees, as we do with the rest of the policies.

The is some consideration about the true distinction between C-ULA address blocks and conventional unicast address blocks. If the address allocations in the C-ULA block are published by the RIRs in precisely the same manner as other unicast address allocations, are able to be entered into the reverse DNS in the same manner as other unicast address allocations, and if the RIRs are not the determiners of whether an address block is actually routeable or not, then what precisely is the distinction between this C-ULA address distribution function and the conventional unicast address distribution function? Why are C-ULA address necessary? What problem is this proposal actually attempting to solve here? And if the problem can be identified clearly then the subsequent question is whether there are alternative mechanisms that could solve the same problem in different ways?

Why using global unicast for something which already has an allocated prefix since it was designed for that by IETF ? For sure there are alternative mechanisms, as usually there are many solutions for doing everything :-), and that may require an alternative ID if we can't achieve consensus on this one.

i.e. What is the problem that C-ULA addresses are intended to solve and what alternatives are available to us in looking at this problem? So far I have yet to see the proposer of this policy address this quite basic question. I suspect that the proposal would be a fair deal clearer in intent, and a fair deal clearer in terms of whether or not the proposal should be adopted, if we all clearly understood what the underlying problem (or what shortfall in the existing address distribution mechanisms) is that this proposal is intending to address.

I tried to make it clear in the proposal text. I think it can be summarized as: The issue is avoid wastefully using global unicast resources for infrastructure microallocations if it can be done with a prefix from another block which is already reserved for this type of functionalities.

********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

Some have raised the concern (in other lists) that the ID is expired, so I'm telling that before it comes back here again. The way the policy proposal is written is to avoid entering into implementation issues (which as said, I believe should be decided by the RIRs staff), and thus in principle, if the authors change implementation aspects, the policy proposal don't need to be modified. Regards, Jordi

De: Geoff Huston <gih@apnic.net> Responder a: <address-policy-wg-admin@ripe.net> Fecha: Thu, 03 May 2007 11:33:37 +1000 Para: <jordi.palet@consulintel.es>, "address-policy-wg@ripe.net" <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] 2007-05 New Policy Proposal (IPv6 ULA-Central)

At 10:30 AM 3/05/2007, JORDI PALET MARTINEZ wrote:

...

Hi Geoff,

I guess it is important to clarify that the authors of the draft are working on a new version. I've not yet seen it, so I'm not sure if it is addressing already any of your points below.

I'm getting very confused - If I understand the situation at this point in time this is a policy proposal in the RIR process that is based on a document that is actually in preparation at this point in time?

If this is indeed the case then possibly you might wish to consider suspending the policy proposal until such time as the document is completed.

regards,

Geoff

********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

Shane Kerr wrote: [..]

The basic motivation for local IPv6 *seems* to be RFC 1918 space (10.0.0.0/8 and the like) for IPv6. That makes a certain amount of sense. RFC 4193 space basically works like that today, right?

Yes.

The motivation for a version with a central registry however is not so obvious to me. The only justification I can think of is that you can be sure not to pick the same /48 as someone else has picked. But the chances of that are *billions* (that's "thousands of millions" to British folk) to one!

Correct, though this is for bean counters of course who don't want to take that chance.

If you consider a 1:10000000000 odds too great for you, then there are a couple other options:

- get a /48 from someone with an RIR allocated block

This is IMHO the best option for those beancounters. If they really are so desperate to get a block, get one from the RIR. Especially as most likely one will be connecting to the Internet one day or another anyway and then suddenly you either need to renumber from your private block or pay enough cash to get it routed anyway. IMHO, Central ULA has no place, folks requiring that strict kind of allocation should simply get a publicly registered block. There is a side reason for me to say so, and that is simply because folks will want these blocks and start doing NAT for IPv6, just because they 'like it so much' and 'are used to it'. Discouraging that as much as possible is a good idea to keep the Internet end-to-end.

- take an IPv4 address that you have been assigned and convert it to a 2002::/48 block

Very sane one, but it might cause issues when you are going to try and route it to the $world as you will be forcing yourself to use other folks 6to4 relays, as such this is not an option. Remember you should not announce prefixes smaller than 2002::/16 into BGP. [..]

I don't have any answers about DNS, because frankly I think reverse DNS is stupid, and IPv6 reverse doubly so. Hey, I'm prejudiced, I know. :)

It's very handy in a lot more cases than you think ;) In combo with DNSSEC, or the believe that the DNS is giving you the right answer it can be used for access control based on DNS-labels/domains instead of IP numbers. It is great for logfiles (if you trust dns) and makes traceroutes much more visible. There are a load of other options that a lot of people do like and thus require it for. BUT as these would be LOCAL networks, the folks running these LOCAL and non-internet connected networks can easily set up their internal internet-disconnected DNS server to do the reserve resolving. Just like is currently already happening for RFC1918. This also means that it might be good if AS112 folks start adding these prefixes to their nameservers so that they can catch those prefixes. (or is it already being done? :) Greets, Jeroen

On 5/4/07, Gert Doering <gert@space.net> wrote:

Hi,

On Fri, May 04, 2007 at 11:54:22AM +0200, Shane Kerr wrote:

...

The motivation for a version with a central registry however is not so obvious to me. The only justification I can think of is that you can be sure not to pick the same /48 as someone else has picked. But the chances of that are *billions* (that's "thousands of millions" to British folk) to one!

Take the "birthday paradoxon" into account. Chances for a clash with "someone else in the room" are actually much higher than the chance for a clash with "a *specific* number out of the ame pool".

The general solution of the probability of a collision after d draws from n possible values is given by: P = 1 - ((n!) / ((n**d)((n-d)!))) Given that the value for n is 2.199,023,255,552, then the objective is to find the lowest value of d for which P is greater than or equal to 0.5. In this case the value for d is some 1.24 million. http://draft-huston-ipv6-local-use-comments.potaroo.net Geoff

At 11:08 PM 4/05/2007, Wilfried Woeber, UniVie/ACOnet wrote:

Geoff Huston wrote:

...

On 5/4/07, Gert Doering <gert@space.net> wrote:

...

Hi,

On Fri, May 04, 2007 at 11:54:22AM +0200, Shane Kerr wrote:

...

The motivation for a version with a central registry however is not so obvious to me. The only justification I can think of is that you can be sure not to pick the same /48 as someone else has picked. But the chances of that are *billions* (that's "thousands of millions" to British folk) to one!

Take the "birthday paradoxon" into account. Chances for a clash with "someone else in the room" are actually much higher than the chance for a clash with "a *specific* number out of the ame pool".

The general solution of the probability of a collision after d draws from n possible values is given by:

P = 1 - ((n!) / ((n**d)((n-d)!)))

Given that the value for n is 2.199,023,255,552, then the objective is to find the lowest value of d for which P is greater than or equal to 0.5. In this case the value for d is some 1.24 million.

That formula does apply under the assumption(s) that the draws will be evenly distributed across the value space, correct?

Yes, thats correct. Geoff

The general solution of the probability of a collision after d draws from n possible values is given by:

P = 1 - ((n!) / ((n**d)((n-d)!)))

Given that the value for n is 2.199,023,255,552, then the objective is to find the lowest value of d for which P is greater than or equal to 0.5. In this case the value for d is some 1.24 million.

http://draft-huston-ipv6-local-use-comments.potaroo.net

Are people going to pick random values? I'd expect a more likely outcome to be that they will pick strings that are easy to remember. How many collisions will there be if that is the case? Remember DEADBEEF? --Vince

Randomness could be a natural outcome if the default configuration for SOHO routers was to create one and bury the ability to specify it under some 'Advanced/Experts-only' option. There is a 'need' for this space to satisfy Enterprise network managers that have external partnerships and are unwilling to deal with collisions no matter how unlikely. While these organizations could use their PI space for this, they don't want to because that ends up impacting their internal routing due to the number of deaggregates that get announced. Tony

-----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg- admin@ripe.net] On Behalf Of Jeroen Massar Sent: Friday, May 04, 2007 10:17 PM To: Vince Fuller Cc: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] 2007-05 New Policy Proposal (IPv6 ULA- Central)

Vince Fuller wrote:

...

...

The general solution of the probability of a collision after d draws from n possible values is given by:

P = 1 - ((n!) / ((n**d)((n-d)!)))

Given that the value for n is 2.199,023,255,552, then the objective is to find the lowest value of d for which P is greater than or equal to 0.5. In this case the value for d is some 1.24 million.

http://draft-huston-ipv6-local-use-comments.potaroo.net

Are people going to pick random values? I'd expect a more likely outcome to be that they will pick strings that are easy to remember. How many collisions will there be if that is the case? Remember DEADBEEF?

If one is doing that, then why even bother using ULA's. Just use 1234::/48 or something similar then ;)

One can't engineer around stupid people unfortunately...

Greets, Jeroen

Jeroen Massar wrote:

Tony Hain wrote:

...

Randomness could be a natural outcome if the default configuration for SOHO routers was to create one and bury the ability to specify it under some 'Advanced/Experts-only' option.

There is a 'need' for this space to satisfy Enterprise network managers that have external partnerships and are unwilling to deal with collisions no matter how unlikely. While these organizations could use their PI space for this, they don't want to because that ends up impacting their internal routing due to the number of deaggregates that get announced.

Can you elaborate that last sentence? Do you mean that these people do not know that there is an 'aggregate' knob on their routers and that they will be deaggregating this prefix when announcing to the Internet?

No. Consider a global organization that has multiple suppliers/partners with private interconnects for specific business functions. The goal is to restrict the private interconnect to use for the specific task, not to leave it open for all traffic between the organizations. To manage traffic they deaggregate the partner network and announce the specific part for the private link, and the aggregate via another path for the rest. The result is 2x entries for each partner. This is avoided in IPv4 by using nat to create an artificial internal aggregate leading to the edge where these partner networks are connected. By using the central ULA (and more efficiently by carving that by region), they can recreate this internal aggregate model while avoiding any possibility of collision.

As I mentioned, we can't engineer around stupid people. The default of those routers should be to aggregate to resolve this 'problem'.

What is the difference between having: 2001:db8::/48 + fc00:db8:5678:1::/64 + fc00:db8:5678:2::/64 and: 2001:db8::/48 + 2001:db8:5678:1::/64 + 2001:db8:5678:2::/64

Nothing. If they announce the full deaggregate for the ULA space the impact would be the same as using PI deaggregates. The value is to have fc00:/8 lead to the demarcation for all the partners, rather than explicitly announce every partner subnet throughout their own organization.

For both prefixes (excuse the ULA central bit) one would have to go to the registry to get it, and as one gets PI, one is already going there, why go there twice and claim 2x /48, which most likely is waaaaaay too much anyway.

Did I misunderstand something in your statement?

Greets, Jeroen

Jeroen Massar wrote:

Tony Hain wrote: [..]

...

...

What is the difference between having: 2001:db8::/48 + fc00:db8:5678:1::/64 + fc00:db8:5678:2::/64 and: 2001:db8::/48 + 2001:db8:5678:1::/64 + 2001:db8:5678:2::/64

Nothing. If they announce the full deaggregate for the ULA space the impact would be the same as using PI deaggregates. The value is to have fc00:/8 lead to the demarcation for all the partners, rather than explicitly announce every partner subnet throughout their own organization.

Ok, if I understood correctly (guess a little drawing would help even more ;), you mean that, taking the above example, they will only have a 2001:db8::/48 and fc00::/8 route in their tables and nothing else? Otherwise they would end up with a large amount of /64's in their internal tables pointing to the partner.

Essentially this is the goal. Every situation will be different, like if there are 3 regional interconnects between a particular pair of companies that would likely mean 3 more explicit routes for the fc00/8 block, but not necessarily one for every partner in each region.

Also, they know that fc00::/8 is 'private' and that they need to firewall that in a different way. Which is a good property.

But how is this different from having a single default to the edge routers + firewalls, which take care of the routing tables to the endsite? You then have a single location to maintain, and those entries are then popping up only there and nowhere else.

That would be true if the demarcation for the default route and the private interconnect block were in the same place. If the Internet default and the private peering are on different routers sets then you need a way to split off the traffic.

Also, this sort of implies, from what I understood, that every host on the network will get multiple addresses, at least one from PI, and one from the ULA prefix. I do hope then that source address selection is being done correctly. Fortunately, fec00::/7 is at the top of the address space and thus can't easily be confused, like with 6to4 which is in the 'middle' and suddenly does get chosen for 2003::/16 and all other addresses, while the 2001::/16 prefix is used for 2001::/16 addresses.

Address selection is a mystery to most, but we need to fix 3484 to replace the references to SL with ULA, then the right thing happens. Tony

Leo Vegoda wrote:

On 8 May 2007, at 12:01pm, Tony Hain wrote:

...

Randomness could be a natural outcome if the default configuration for SOHO routers was to create one and bury the ability to specify it under some 'Advanced/Experts-only' option.

Do you see a lot of demand for separate internal and external addressing in SOHO networks?

Separating reachability is what firewalling is all about... 'No route' is more effective than the fastest deep packet inspection engine. Consider that the default configuration for a printer should not be to bind to a global prefix because that is generally a local function. There are more examples related to home automation of what is to come, more so than what exists to create current demand. Either way, it is trivial for a SOHO device to generate the random prefix and avoid the problem of people all selecting the same thing. If it gets used or not is a completely independent discussion. Tony