These are unedited transcripts and may contain errors.

Address Policy Working Group, 6 May 2011 at 9 a.m.

CHAIR: Good morning dear Working Group. I am happy to see so many of you here. It was a good party yesterday. I understand anybody who has problems opening their eyes this morning and not finding the room.

Anyway, originally I hoped that we would have a pretty light agenda for Friday and would be able to just tell people, oh we have start at 9:30 which something database traditionally did because if there was no so much to do. Unfortunately, we have a pretty packed agenda, so we really start now.

Sort of some things exploded on the mailing list over the last day, so we have to take time for that.

That's the plan for today. First, quick roundup from Emilio on the document cosmetic surgery's project, then me again doing basic housekeeping on the first three of these open policy proposals telling you where they are in the process and what the next step is going to be. Then we have the certification policy and we will have discussion on that because it came up that there was need for discussion, so we do it. At about ten o'clock, we have Jan and mark here to explain a bit on the technical background on the 6RD protocol and how it affects addressing in an ISP network and basically, with a proposal to potentially change the addressing policy to take that into account and to collect feedback from the room.

And basically then if anything else shows up, it goes here. If not, coffee. Anything else I have been missing? Anything that needs to be reshuffled? No. Then it's basically Emilio.


EMILIO MADAIO: Thank you Gert. Good morning Working Group. Okay. What are we going to talk about? I'll trying to be brief and not too quick. This is a cosmetic surgery project, a project the NCC was tasked by the community sometime ago. I'll give you some history about how this started and the actual status, the current status and what are the next steps.

Something is better to clarify right now. That has nothing to do about /W* changing policy. It has nothing to do with the PDP, that's the policy development process. That has more to do as you can already see and read there with cosmetics of the policy. Everything started at the RIPE 57, where the community expressed their complaints that related to the fact that policies over the time were becoming patched and the visibility was reduced. It's an obvious consequences of the fact that the Internet industry is changing, the community changes, the needs are changing and the policy had to change as well. So new policies were going to be published and new changes to current policy happened, and they were not completed in line, they didn't have a text, a format, a layout that was very con/TKPWRAOUPBT, there was some discrepancy, not in terms of the policy content and the policy implementation, but more cosmetic level.

So RIPE 58, the NCC presented a project plan. Basically we drafted ?? the policy office draft in?house the new policy, the new version, new text of the current policy. The Address Policy Working Group group chairs over this operation. The time line for the policy drafting and approving is about 15 working weeks depending on the complexity of the policy. It can be more or less. And the project included the six policy documents to review and to update.

In RIPE 59 the project was finalised, there was a presentation what the NCC was going to do and the implementation started. All I said is available here and some more. Here you can find either the history of the project, how it came out. You can find the announcement we made in the Address Policy Working Group mailing list. You can find the policy we updated, we re?draft so far and the one we are redrafting new.

The status: We have available this policy: RIPE?496 (obsoletes RIPE?463) it took sometime because there was a discussion I want to spend some words on this so to give you an example between PDP and this type of activity. Basically this policy was redrafted twice. There was a version 1 and 2 and this is because a discussion started on the fact that there was a section that changed too much the policy. It didn't change just at textual level, it was not just an editorial improvement, it was more like ?? it was seen by the community, a policy content change, and in the RIPE 60, if I recall correctly, started the consultation with the community between the NCC and the community to decide what to do with that specific change that was included in the cosmetic surgery project and that was decided that it was accepted as a change. There was some kind of need for that specific change but didn't belong to the cosmetic surgery project. It belonged to the policy development process.

What is going on now? These are not the next steps ?? this is something that already took place. We re?draft three different documents a merged into one and as you can see, these are all IPv6 policies. Something that should be of your interest. There is a lot of to say really to that. There is, the re?draft, you can see that was published some weeks ago, included also some other inputs we received in Rome in the last RIPE meeting, something I mentioned when I talked about the policy proposal 2010?07 when, again, there was an intention of the community to change something in the policy and it was more at cosmetic level than a real policy level. The review of the community started on the 18 May. These are are two interesting URL ?? I didn't use the short form. You have two different versions of the draft. I mean two different layouts. One is the ink that stands for included, change included. The other one stands for high, like changes highlighted. So, you have in the included, the proposal RS D policy, this is the future if the community accepts the redrafting. The other one is as the ?? the comparison between the old policy and the new policy text. So you can really see the difference. I can make it more ?? I cannot make it more clearer than this without offending your intelligence, to I really would love you to have a look at this and give some kind of input in the Address Policy Working Group mailing list.

And that was my brief presentation. If you have questions?

CHAIR: So any questions or comments from the room? Well most of the work is going on in the mailing list anyway, so that would have just been for clarification only. Okay. Thank you Emilio.

CHAIR: Thank you for saving time because we are running a bit short today.

GERT DOERING: And going back to my slide. So, I am going to give you a short overview of what's been going on with the open policy proposals that are in the formal system right now and have not been covered yesterday already.

The sequence is not numerically, but /SORLT of like how it was easier to lump them together. (Sort) the first one is 2010?01, that's the temporary Internet number policies. This policy proposal basically reworks, or aims to rework the framework that the NCC has fora signing temporary Internet numbers. IPv4 addresses, IPv6 addresses and AS numbers. There was always something for expermanent and this sort of widens the scope for any sort of temporary things.

The important bit about that policy is actually that it directs the NCC to reserve a pool and so it was fairly important to actually get it in place while there is enough addresses to actually set up a pool. We had that on the mailing list, we agreed that we would go forward even if there were some disagreements on specific wording in the texts to have the pool in place and then work out the /WREUPBG else. The Working Group Chairs that's well mostly me, neglected one important bit here that's actually inform the mailing list on the discussion that happened at the last RIPE meeting. So, when we went through last call, after last call, a policy proposal goes to the Working Group Chairs collective where all the Working Group Chairs check that the policy process has been followed properly and they bounce it back and said you have done some discussion at the RIPE meeting, you had people actually stand up and say, yes, I have voiced my opinion on the mailing list, but I want to amend it and say even if I was critical, I don't want to hold up the proposal. So, important bits happened and we had not communicated this properly back, so we actually had had to do last call again. The second last call is going to end next week and we have not received any comments so far, so by common practice we take that as an agreement and basically, I expect this to become policy then after next week.

2006?05, the IPv4 PI assignment size. That's basically, if you need IPv4 addresses, PI addresses and you can only justify a handful of machines but you need a /24 because otherwise it's not going to be routed, what are you going to do? Common practice these days seems to be massage your numbers long enough that it looks like a /24 is needed, which people might also call lying to the NCC and that's not a good practice. So, this policy proposal basically sets a framework that if you need numbers and your numbers don't make a full /24, you can get some, well, slack to actually be assigned a /24 or multiples of /24. Like F you need 270 numbers you don't get a /24 and a /27, but a /23. There was general agreement that this is a useful thing, because a policy that encourages lying to the NCC is not useful. So, taking into account reality instead of just idealism, there were some concerns that the wording was too /KHREU CAIDA, that the rules were sort of like weird and the proposer Nick Hilliard, took that back with him and said he would work it in and send in a new policy text and he planned to do that by Christmas and well, /TPHR?FPLT complicated) and he had had health issues and is not able to come here as well, so this has been stalled.

Sander talked to people and we got, we volunteered a co?author to work on the proposal, that's Paul /HOS at the time err, I hope I pronounced that, that has been active in the community for awhile, knows what it's about and will work with with Nick to bring you a new version of the text soon. We have checked with Nick, Nick is fine with that, and so there is no bad thing here like stealing away proposals.

Then we have a new one, which has a slightly inconvenient long title, that's a global policy proposal. This time it's a global only policy proposal, while the last attempts at this problem always mixed in local policy and global policy and then usually the ARIN AC changed the wording and then the policy went nowhere because you can't have a global policy /WEUGS not identical in all the regions (which is) basically this whole problem space went nowhere for the last couple of years and burned up quite some cycles. So this is a very light wide thing which governs what IANA is to do with address space that happens to be at IANA after the runout, so now. And it doesn't do anything about returning to IANA. It doesn't do anything about ruling local transfers and anything. It's basically really the global bit only.

Originally Phillip Smith planned to be here, but well, there was trouble with visa and travel permits and stuff, so I am taking this on.

This is the details, what the policy is about. The problem statement is pretty occupy: We have a global policy that sets the rules under with which IANA gives IPv4 address space to the regional registries and that policy talks about /8s only. So if for some magical reason a /16 ends up at IANA and there is a regional registry in need of IPv4 addresses, they cannot have it, because there is no policy that governs how IANA can actually give out that /16. The proposed solution is two times a year, IANA basically just counts what they have in stock, wherever that came from, returns hidden holdings, whatever, divides that by five, rounds it down to the next CIDR boundary and it distributes to every RIR that has a need. So, basically, today that would be APNIC and soon, all the others would get their fifth as well.

There is a safeguard if the remainder is less than a /24, then nothing it given out because that sort of kind of useless. There is more text in the policy proposal of course, but basically it's easy to implement, easy to follow and easy to understand with no funny strings attached and so on. So, it's housekeeping, it's filling a gap where we sort of have missed policy. So, I encourage you to read it on the mailing list, to read it on the policy proposal website, make your mind whether you think this is useful and comment on the mailing list. If clarification and questions come up, we can spend a few minutes here discussing it because it's a new proposal that has not been brought here before. Okay. Anything on that? Two or three questions, comments, would be welcome.

AUDIENCE SPEAKER: Wilifred /WOEB err: What is the reason for the sort of artificial delay with this fixed time, with this fixed period of just two times a year? Following up on your proposal, like IANA would receive a /16, and it would receive that /16 the day after the previous round of potential reallocation. What's the reason of waiting for another six months if there is a need for those addresses? I can understand that you don't want to do that each and every time a tiny pies of address space comes back, then there is little use of it. But under the situation that we might receive a /16 or low and behold a /8, then I don't see why we should wait for six months minus something before we redistribute that. I am wondering whether it wouldn't be more useful sort of to think about a minimum size accumulation at the IANA back yard and as soon as that is reached, we just treat it as a redistribution. That's just an open question.

GERT DOERING: I wouldn't actually be able to answer that since I didn't write up the proposal. I can guess and my guess would be that this is too avoid fragmentation, because if you sort like redistribute it every time something comes in, you will have a /SH?RB 20 come back and then out goes the 23s and the next round you have another /20 and so if you sort of like pool it for six months, then you can actually give the RIRs something a little bit more big another size. Maybe there will not be anything coming back anyway. So...

This might moot, but if something comes back, it sort pools it for six months and then distributes again. I encourage you to actually ask the question on the mailing list because the proposals are really in the list so they can give you a proper answer. One of the dangers we have here is that if we start to actually modify the proposal, then it will not become a global proposal again because well it has to be the same text ?? well, the rules have to be the same in every region, even if some words differ but it's easier on the NRO if we actually have the same text in all regions. So unless other regions change this, I would pretty much have this as, take it as it is or refuse it as it is but not fiddle with the words. We have had that in the past and it caused pain.

So we go to the sore spot of this meeting ??

AUDIENCE SPEAKER: Brian Nisbet, because we didn't have a chance to comment on the previous policy. 2006?05, yes, I have a very rude question: Is there any chance that policy is going to reach implementation before we hit the last /8, at which point it becomes moot and...?

GERT DOERING: That depends a bit on you folks.

BRIAN NISBET: There is time lines in the policy development process and predicted run out is...

GERT DOERING: Okay. I can maybe hand over to Emilio to say what the fastest is that we can go if we had a new text next week and you all agree that this text would be useful.

EMILIO MADAIO: The assumption is that the community has a very clear idea and is goes to publish them in the mailing list, we have four weeks review phase that actually can be shortened depending by the input we receive to move to review phase and there is then a four fixed weeks of last call before implementation. And I would like to add also at this, in this instance a couple of weeks to run the impact analysis over the proposal, that should be kind of quick either because we know already, we are the NCC know the troubles of text and there is the interest in the community to speed the process up. So, count on two plus four plus four.

GERT DOERING: So some ten weeks if we really, if we are really fast about T so yes, this might become moot, but I am still not ?? well, of course I could just drag it along and then it will fall off the table /PWUP that's not a way to run the process.

BRIAN NISBET: I agree and that's fair enough. I am just ?? but looking at what had been predicted and and indeed what Geoff was saying about what happened in APNIC, I think ten weeks ?? /W?PL there might be one allocation given to this if we are very lucky or unlucky as the case may be. That's fine, let's do the policy, I just wanted to ask the question.

GERT DOERING: Thanks for bringing it up, might have mention it had myself that time is running a bit short on this given that we have been discussing it for five years.

AUDIENCE SPEAKER: Geoff husband tonne, APNIC, even if, and I'll directly answer that question, even if the last chance rush happens in the RIPE region, the most /PEZ mist I can estimation in terms of how long RIPE has gone is around about four months from today and the most likely is around six months (pessimistic) and the four months really is everyone gets excited and they all quay up to RIPE and want their /enormous amounts of space, so yes, Gert /TKORG is a very quick man and you are all very motivated and so on you could scrape in with a week or two to spare.

GERT DOERING: Okay. Thanks. So, trying again to reach that slide. The plan for today was basically to present that this certification, initial certification policy, last call. There has been not that much going on on the mailing list, and but there was some positive feedback, so we moved forward and last call nothing has been on the list, so we take it as consensus and well then, basically, this week the mailing list exploded with I don't know, something like 100 e?mails on that topic and so we reshuffled the agenda and we basically have something over half an hour to give this proper consideration, and see what comes out of it. I am handing over to Sander here, because well, sharing responsibilities, he is going to sort of drive the proposal and I try to stay completely neutral and judge the process.

SANDER STEFFANN: So, this week some concerns were raised on the mailing list about the certification proposal and the risks associated to building this. So, we tried very hard to address as many of the issues raised as possible. And one of the issues was about what happens if some law enforcement agency or company starts a lawsuit and, or comes to the RIPE NCC and forces them to revoke a certificate or reassign a certificate or things like that.

So, because we are no lawyers, we actually asked the NCC to get legal counsel and they asked some external lawyers on their opinion of this. This is the full response that we got. It's also posted to the mailing list, so if you want to read it that might be an easier way, but basically it comes down to that in the RIPE NCC's view, based on this analysis, the RIPE NCC cannot be ordered to revoke resource certificates.

So, this is of course the current situation. Laws can change and we can not, we don't have a nice crystal ball to see what will happen. But based on the current sayings, at least this doesn't seem to be a big risk. So, I hope this, this addresses parts of the concerns. Some of the other concerns were about introducing a tree structure, or or a hierarchy and do we want this for the Internet or not, and luckily, Rudiger prepared a slide presentation to address those issues. So I would like to give the floor to Rudiger and he will give you some feedback on the other topics.



RUEDIGER VOLK: Thanks, good morning. Actually, I would have preferred to talk about a little bit of different stuff moving actually deployment further, but well, okay, with the concerns that have been raised on the mailing list this week...

Anyway, just let me introduce myself, Rudiger Volk, I have been working for Deutsche Telecom since '95 and in RIPE since the very beginning, and all this week I think we can say concerns about threats of using RPKI for RIPE have been raised. And this is a little bit impromptu, but...

So, actually I think there are quite a number of things that would be interesting to discuss about how we are dealing with this within RIPE and the RIPE NCC activities and my comments on the last two cycles of the discussion included interest to that in fairly big extent, but well, okay, today I want to look at what threat is there and what does that mean technically and point a little bit back to where and when we actually had a little bit of discussion about it and back then, actually, it looked like analysing the technical ?? the threats from the technical side, indeed offers ways for mitigating the threats.

Well, okay, first of all let me quickly go over a few questions. One question is: Well, okay, is there a reason to do anything? Is there a threat in using unsecured routing information in the network? Well, okay, we have had technically detailed discussions of that and well, okay, I am sparing you ?? okay, this is not the audience to discuss it right, this is the Address Policy. The thing that I see is really important to note, the operators of the large networks probably most, but well, okay, in general the question has to be put to the operators whether they perceive a real threat and a need for a solution for getting the routing information secured or not. They are the people who are responsible for running network services reliable, and well, okay, if they don't do that right, their customers will go after them and well, okay, the politicians and regulators will and should go after them if they take up this responsibility right, there is not much need for anybody going after them.

In theory, I could do a show of hands whether operators are around here are concerned, but well, okay, I am sparing that exercise.

So, what solutions for the threats of the unsecured routing information are are there? Well, okay, again, we don't want to go into technical details and look all through. What I think is pretty clear, the current situation with ?? for the security of routing information is insufficient security and the tools that are available and the infrastructure for securing things is broken in many ways.

Next question is: What solutionings are available or well, okay, actually what solutions have been worked on? Solutions that are pie in the sky and would need to be started right from the ground probably are not really interesting. And looking at those questions, again I said I think it's pretty clear the current situation is not satisfactory and things are broken and solutions are indeed needed and luckily, at least one pretty solid solution has been worked on for quite some while and with pretty ?? with quite some effort, and my previous, what do the operators say about it? Well, okay, we don't have that much of a representative pool of what the operators mean. What I can point to is, for example, internet society organise /ROUPB tables, some were in autumn of 2009, where where some of the large operators got together and looked at it and I reported on that at RIPE 59 Lisbon. I am giving you the URL report which gives you, when I look at it extremely today confusing and surprisingly my presentation slides from the Friday morning Routing Working Group in Lisbon have disappeared from the RIPE archives. Nevertheless actually there is an ISP column report for Lisbon a nice one paragraph summary.

Again, /AOU /TOEP yen proposals can look very tempting when people are scared, but /AOU /TOEP yen proposals can promise everything but well, okay, nobody knows whether they ever can differ. So, at the moment ?? so, I conclude ?? the top line ?? at the moment RPKI essentially is the only house available in town.

So, in Lisbon we had a little bit of a look at what are the /SRUL another /?BLTS of RPKI and yes, the hierarchal system first points of attack that can be very effective. The analysis we did was that well (vulnerabilities) the attack investigator that is there is pretty limited and well, okay, in Lisbon, we also had some discussion about what can be done and well, okay, my conclusion was, there was ways to deal with it. The one attack investigator that is really interesting is the, well I called it back then unexpected revocation. Well, okay, certificates being pulled for whatever reason that well, okay, doesn't kind of comply with the community's notion of what's appropriate, and well, okay, that includes a staff member going /PWERS /ERBG, that includes armed men walking in somewhere and forcing bits to flip, and (/PWERZ /ERBG) billion okay, it includes ?? it includes essentially everything, and of course, whatever, whatever, whatever also unarmed law enforcement might affect.

For dealing with the stuff, well, okay, the first thing is to influence and make things safe where we actually have influence. And that is, make sure that the rules and processes that we agree with the RIPE NCC on actually do not have holes and make sure that the actions that are taken comply with our notion of what's right. Of course we can not be sure that they go /PWERZ /ERBG, or not /PWERZ /ERBG rather. Anyway, one would expect that well, okay, as a community based organisation, the RIPE NCC usually actually does what we want. And well, okay, it's operating in an environment that looks pretty stable. There are countries and legalen /SROEURPLTS that are much more unpredictable. Well, okay, the sea level can be concern around here but well that's moving pretty slow.

So, we can assume that we have to do ?? have to deal with a potential of very rare exceptions, but anyway within the PKI system the final thing of what is valid and what is not valid is not with the authority handing out the certs, it is with what they call the relying party. It is the guy who is validating the certificates for using it. And actually Steve Kent presented in Lisbon a little bit of impromptu about details for that. I think the conclusion this is, well, okay, things can be done there. It may be a little bit more nasty work than the developers like, but yes, there are ?? we can effect things there. But, well, okay, so let me now have a little more in?depth look in what do we need for making this effective. The notion that the relying party is the final authority is a pretty high level concept, and the interesting question is: How do we empower relying parties to do it effectively?

So, the first very simple observation is, we have to work a little bit on the relying party's software so that, well, okay, a relying party will not be empowered to use stuff if it's really hard. We have to make it easy and well, okay, I think that's a small matter of software programming. Well, okay, it can be a lot, but that's not really a conceptual barrier and my claim that this can be done, I think, is not /AOU /TOEP yen.

Again, there is work needed and there are people needed who actually push this. Well, okay, then of course we need information that the relying parties can use about what used to be in the system when an exception happens? What was there before the strange thing happened? So that the tools we are giving can be used by the relying party to say, well, okay, I don't believe this revocation, I'll use the old information. Organising an independent, redundant, backup archive of RPKI information looks like a thing actually very easy and something where the Internet is really good in creating protection. Also needs some work, so it's done right. But, eminently doable, feasible.

In addition to that, a little bit new is needed. We actually would have to organise some information exchange so that someone who is monitoring or complaining ?? well, okay, monitoring the changes in the certificate system and finding something that has suspiciously been revoked actually can tell the community, or someone who says, well, okay, the RIPE NCC decided to kill my business for no good reason, don't believe the revocation, can actually tell the relying parties that they should make their choice to not believe the revocation.

Again, that needs work and well, okay, actually figuring out may be a hill bit of technical protocol, but more the rules, how the exchange between interested parties works needs a little bit of work, but it looks like something that can be done and something where the Internet community isn't really that bad about if they are interested in doing it.

So, what would be the consequences of actually doing ?? empowering the relying parties in a way like I tried to sketch?

Well, first, remember we can expect that exceptions to what we want to deal with are rare, few and infrequent anyway. With a backup infrastructure and making it easy for the relying parties to actually work around exceptions, the attack vector of taking out certificates comes damned unattractive to parties that are reasonable. If people are scared about developments on the political and law enforcement side, well, okay, I think it is a reasonable assumption to assume that they will be operating reasonably. Well, okay, we know once in a while in one place or the other unreasonable stuff happens there, well, okay, we can't do anything about that anyway, and our system actually can deal with all the exceptions. (Vector) and this being scared that this would offer an attractive attack vector I think books moot if we can put in place such an exception handling thing. What I can't tell is well, okay, will we actually, will we actually go into a situation where well, okay, the exceptions are are so rare that nobody cares to put in the effort to keep the exception handling system in place.

Again, short: I think the threats that are there in the RPKI can be mitigated. However, everything has its cost.

Will it be done? Well, okay, that's an interesting question. I can breakdown that in a couple of other questions: Who is concerned about risk? Where and how will work on the relying party software happen? And well, okay, how and where do the other parts of the sketch system? If people are not ?? if people are concerned but there is no willingness to put in resources to fix things, well, okay, what can we help? But well, okay, I wouldn't think that such concerns can be taken seriously.

I guess ?? I don't want to talk too much about this. Of course for getting things done, we actually have to breakdown and figure out who could be doing something and well, okay, the way we have been handling the certification stuff within the RIPE community so far has not been a history of high activity, so, with will okay, I think a little bit of effort in how to organise things and find resources is needed.

That's it. Thank you.

SANDER STEFFANN: Thank you Rudiger. So, basically, one of the first things Rudiger actually mentioned is making sure that the RIPE NCC does issue the certificates in a way that we want them to issue the certificates and have good policy for that. So that is actually the point that this policy proposal is about: All the other things are technically even outside the policy proposal. So, that's one thing to keep in mind.

On the other hand, Steve kent has been mentioned, his presentation, and I think it would be good to give you the microphone now.

AUDIENCE SPEAKER: Thanks. Steve kent, BBN. The one thing I want to say is that in the aftermath of the discussion that took place in Lisbon, we developed a technical description and mechanism for empowering relying parties in many ways of the sort that we had talked about there. There is a side err Working Group draft on this called "Local Trust Anchor management" and the BBN relying party software implements that capable so it gives a relying party to ability to take old information, as Rudiger was saying, that believed in the past (implements) plug it into the system and have you as a relying party now believe what you used to believe before something bad happened that you say oh I don't believe that should have happened. So, that is part of the relying party software in open source form that we are releasing and continually updating. It's not trivial to manage this of course. Whenever you start wanting to redraw the wiring diagram for something like this, but there is a description of how to do T it will become an informational RFC in the future and our software implements it now. So it's not just a something that one could do. It is something we have done.

SANDER STEFFANN: Okay. Thank you. That's good input. Randy?

RANDY BUSH: Randy Bush, IIJ, just further on Steve's description, actually the local Trust Anchor document merely tries a way of using what is de facto in the specifications. So, all relying party software, including the stuff that Alex described in his futures talk Wednesday, will have that capability automatically.

I believe, though I had some quibbles with the technical details of RIPE's current certification capabilities, that they are essentially on the right track. I am sure we all wish they were further down the track, but that's life in the big city. I wish many things except my age were further down the track.

I think it will be important for the NCC software set to do relying party cache as soon as possible, because that cache is the customer of the current publication, and I think having a customer will cause the publication to be better and address some of the problems I have with it. But, I think RIPE is, the NCC is definitely on the right path and so forth.

As far as Rudiger's suggestion of having an exception mechanism. Today's exception mechanism is the NANOG mailing list I think, that did bail us out of the YouTube incident, it's a reverse exception and I'll agree that something more formal might be nice. I would warn of course that you are going to have to look at it as an attack vector in itself. I agree strongly with with Rudiger on (vector) we have chosen a path, this is the reality of the situation. I think unlike DNSSEC, the path we have chosen so far has been shown to be technically sound and we don't have serious doubts about it. For those who don't know, DNSSEC took three major revision to say get to it's creaky state that it's in today. I agree with Rudiger in saying let's limit or discussion to the reality of what we have ?? what we might have done in the past.

Secondly, I'd like to apply that same pragmatic criterion to threat analysis: Can we deal with real threats and what is really been seen and not what might occur in science fiction. And those threats include what occurred in Egypt, etc. It's not that I am not saying there aren't real threats to this system from many aspects. But can we stick to as close as possible to realistic scenarios, not what things might be in an alternate universe.

SANDER STEFFANN: Thank you Randy. I see Malcolm standing at the microphone. So since he is the first $1 to actually post a list of concerns to the mailing list, Malcolm, has this taken everything into account that you were concerned about?

AUDIENCE SPEAKER: Malcolm: First of all I'd like to thank you, thanks the chairs for those of you who don't know me by face, I am now speaking as somebody that wandered in oft street and cause the commotion, and thanks to the chairs for taking this discussion seriously and for reorganising your agenda to take into this account. I think we all owe you a thanks for that and to Rudiger as well for his presentation and thoughtful analysis of it there.

I'd like to say, lest anyone be in any doubt, that I am I fully support the ult mate underlying intention behind this policy proposal. I want more secure routing. This will protect against certain kinds of attacks on routing. But if it's going to create more layer 9 attacks than it solves at a lower level, it's a net loss. Unless you think that the routing table is a good place to conduct law enforcement. Now, it's been suggested that this is just science fiction, or that, or Rudiger said that these attacks in his estimation would be very rare. I disagree. I know the sources where these attacks will come from. I work with them everyday. They are very real. Just to give you some estimation of things right now. The Internet watch foundation, a single organisation that is designed to prevent access to, or that acts to prevent access to a single type of content, child pornography information, has over over 400 URLs in its database at any given time. (Pornography) but under various bits of legislation being advanced at the moment around Europe, in the UK, in France and other places, there is consorted effort to require network intermediaries to prevent access to (intermediaries (in so sites Tore seen to have copyright infringement and we all know that kind of material is very prevalent and flits around all the time. So I don't believe this is science fiction. I believe this is very real, clear and present, okay.

Now...

SANDER STEFFANN: This is something we have to see for the future. So, I think Rudiger also assumed in his presentation, this was a real threat, so, we should look at the way to say mitigate. If it happens often or rarely isn't really the point here.



RUEDIGER VOLK: May I remind you the legal statement that you have got up. What we know is, for the RIPE NCC, as long as the Dutch legislator doesn't change the Dutch laws, there is no attack vector on the RIPE NCC at this moment. So it's ??

AUDIENCE SPEAKER: I think you are miss interpreting what counsel said. I have posted a more detailed explanation to the mailing list but counsel said that they do not believe that the NCC can be ordered by Dutch courts undercurrent legislation to revoke a certificate. Maybe not. But there are ?? there is legislation that exists and it is forthcoming, that would require member states to ensure that Internet intermediaries prevent access to to locations.

SANDER STEFFANN: We are running really short on time. Let just assume that these threats are real and can occur, okay.

AUDIENCE SPEAKER: Okay. The next thing that Rudiger said that we, and that Randy just supported is that we should exclude what we might have done differently and just focus on the proposal on the table. And that we, particularly, should not consider what the Certification Task Force might have come up with if we had said to them very clearly, we want to you come up with a way of securing routing that does not allow a single party to revoke certificates and enable these layer 9 attacks, yeah? Now, I think that that's a misjudgement. Because I think that these are significantly serious that it would be worth asking is there in the a fundamentally better architecture that could be pursued on this.

SANDER STEFFANN: In this case if you look at different solutions, I think we should talk to the IETF and not discuss this here because the IETF are the place where these standards are developed, not the RIPE community.

AUDIENCE SPEAKER: Well maybe, but this Working Group is being asked to approve this, and I, for one with, am not going to agree that this is something that we should go ahead with until we have seen some real evidence that we have investigated it according to a requirement statement that I would suggest, that we should be looking to avoid those level 9 attacks. If the answer comes back from those that know far better technically than I that that simply cannot be done, then so be it but we haven't asked that question and I think we should before we give our community consensus support to this.

SANDER STEFFANN: Okay. But I think that Steve kent, Randy and Rudiger have shown that in the system we have, there are protections against the threats, so ?? well like I said, it's an IETF matter, it's a standards matter and the threats that you raised, the concerns that you raised, I think up until now, have been answered. So, I'd like to cut this a bit short. Are there any parts of your, any concerns that you had that have not been addressed by Rudiger's presentation?

AUDIENCE SPEAKER: I think Rudiger's presentation, very helpfully, started something that I would like to see, which is if we go ahead with this, what mitigations can we put in place? But it doesn't address the question of actually should we not ?? rather he dismisses, without argument, the idea that we should instead try something that is fundamentally more proof against that rather than trying to patch these risks at the edges.

Secondly, I suggest to this Working Group, that we should not agree a community consensus in support of this until we know what those things are and are able to weigh the risks with the mitigations in place against the risks that are foreseeable, the foreseeable risks that I am allowing to and that would be my conclusion on this. Thank you for giving me the time.

SANDER STEFFANN: Thank you Malcolm. Shane?

SHANE KERR: Sorry, I have a few things. To respond to that last point, policies can be changed and we have to use the policies that are best at the moment, so, I don't think we have to achieve perfect policy before we agree to do anything.

Another thing is I am a bit concerned with all this language about attacks and threats and things like that. Really what we are talking about is being concerned about a system that makes it difficult to enact local policy, right. So I think it's better to think of it in those terms rather than thinking about threats and attacks and things like that. The concern here is that Dutch local policy may be difficult to override with my own local policy so I think putting that in terms, I think it's a lot less scary and people ?? maybe we can cool down the tone of the conversation.

And finally, I guess maybe a question for Rudiger, because you pointed out that we are only here to discuss the policy part of this but I think the points that you made point to a lot of additional work and discussion that needs to occur outside of that space and I was wondering where you think those conversations should occur?


RUEDIGER VOLK: Well, okay, I put some key words about potential ways forward in my official last slide. Sander, if you want to dial back, I am not completely sure. There is quite certainly the question: People who are very seriously concerned actually will have to consider how they can contribute. The whole thing has taken quite a while and it is a large effort and well, okay, it should not be taken for granted that whatever some community says would be nice to have just happens because that notion is mentioned.

SANDER STEFFANN: Okay, we have two more minutes left. I want to close the lines now. I think we have microphone C first.

AUDIENCE SPEAKER: Hans Petter: I think the simple question is that if this is a mechanism that we need operationally to secure the Internet, is this a good enough first version to work with? And then is it possible to improve that in the future? And if the answer to that is yes, then it's very simple to go ahead.

SANDER STEFFANN: Thank you. Randy?

RANDY BUSH: As just coming in off the street, Malcolm, you may be unaware of the open fora for working on this as far as technology goes, as far as policy goes, that had some fairly long history. And that you should participate in, if you have technical questions about this. This is, as mentioned multiple times, the technical product CIDR Working Group and the IETF and you don't have to go to Quebec city to participate. As in RIPE it is mailing list driven, and there are the documents and you'll find, if you know much about the history of this field, the current design has been done by some of the better known and better qualified security operations legal, etc., etc. Folk in the Internet game. So, certainly welcome new input, but it has not been done idly.

I think, though, the first bullet on that slide that is facing us is interesting to me, because it would re?open an open policy discussion and procedures discussion with within the European region for saying how we go forward from where we are today. I am not suggesting that we use it as a major platform for going backwards, but I do think, you know, that Alex described some future work on Wednesday. I think we all have to support how we go forward as a community and that would be a very good vehicle to do so

SANDER STEFFANN: Thank you. And Dave?

DAVE WILSON: I do want to emphasise a little more the risks of inaction, because everything is a trade off. I think that this is a most optimistic I have ever seen this community about the universal deployment of a new security technology. I am delighted to see that optimism, but I do want to say that if we take very long about it, this may end up in ?? happening in a future where IP addresses may already have been Monday advertiseed in a way we haven't seen before. If that occurs and if we wait that long, we will have (Monday advertised) even more interests railed against securing the infrastructure in this way. So, I am very anxious to see us implement something that we have some confidence in with a view to changing rather than waiting for perfection.

SANDER STEFFANN: Thank you. Thank you all for contributing to this discussion and I think we have now taken away enough time for from our next presenters.

CHAIR:.thanks for the discussion we actually have stolen 15 minutes of time that I promised from these guys so I am going to run into the coffee break and ask you to excuse that, but this is important as well.

One last word on the certificate stuff, Randy, if I may ask you to send a pointer to the technical discussions, to the Address Policy mailing list, that would be appreciated, so that people that are not so good in IETF things can easily find it in the context of this discussion, that would be nice. Thank you so far.

So, now back to actual allocation policy and not intermix routing security policy things. There is IPv6 deployment going on and some hurdles in the way that Jan and mark came to explain to us and ask whether we might want to do something about it in the policy, so please go ahead.

SPEAKER: Jan George. Well I have been approached by many operators, small ones, asking why the hell can't we deploy 6RD because we don't qualify for more than /32? Saying, okay, if we get /32, we can use all the space and give out our clients only /64, and it is not fair. And we also heard some concerns from RIPE NCC staff about receiving the 6RD requests and we decided to put this issue forward.

So, to be sure we understand what's going on and why the 6RDing is messing with our policy, I thought we would ask at the source. So, I I will let mark townsey, one of authors of 6RD FC to explain a bit of the techniques and technology on why this stuff is doing that to us.



MARK TOWNSLEY: Hello everyone. A little bit of review here. 6RD is an IPv6 transition mechanism. In general transition mechanisms either tunnel or translate. They either are stateful or stateless. They are either service provider managed or non service provider managed. All those evils one with you heard about this week, 6to4 and Teredo, generally speak these are are not service provider managed. 6RD is tunnelling, it's stateless and its service provider managed. That's its class.

The reason why this is possible is because of this any of theey little address construction. You start with a prefix from RIPE, from your service provider prefix, unless 6to4 which has the code had a runs over the top. Then you put in the IPv4 prefix for your sub vibe err, RD targets are mainly residential, you get your /32 and you POP it in, boom you have got your IPv6 prefix as it arrives. If you change that, if you don't use the IPv4 address in there, if you don't use the service provider prefix, you are no longer service provider managed or stateless. This is a necessary function of the technology.

It's also tunnelling. It's not translating. So that implies an encapsulation. The encapsulation is IPv6 inside IPv4, protocol 41, such that because of the dynamic mapping thing that we just talked about on the previous slide, within a domain, IPv6 traffic flows along the same path as it does for IPv4. In fact, between home and home, it never even passes through any sort of boarder relay, tunnel relay or anything. It's just residential gateway to residential gateway. So, this is one of the reasons that RIPE labs and one of their analyses said 6RD looks, smells, feel like IPv6. Outside you can't really tell it's happening. Inside, it's really not costing too much to the user because there is an end cap, D cap and that's it.

It's important to understand the provisions model and we'll ?? you'll see why in just a moment. The provisioning model for 6RD, customer edge devices is basically you take your existing residential gateway that knows how to do IPv4, etc., etc.. you turn on IPv6 on the LAN side just as you would nor native, so it's dual stack, right, and inside DHCP 4 or whatever your provisioning mechanism, there is one blob of information that's exactly the same for every single residential gateway in the domain and that's very important, okay. The provisioning model is very attractive here, because you take these four values, again even if you have 4 million customers, those four values are exactly the same for every customer. You can type it into some HEX inside a DHCP 212 option and it's exactly the same to every single residential gateway. And then v6 just works. No neighbour discovery, no DHP v6, nothing.

So a little bit about deployments. It's defined in RFC 5949, commercially available products for at least a year from a number vendors, first deployment in 2007, there are many deployments today. 6 R do it an effectively a life if you want v6 right now.

So here is the real question. That's in the review. These little numbers here, M and N they are variable, right. You can put that IPv4 prefix in a different spot, this is different to 6to4 and the other stuff, depending on the size of your ISP prefix. You can also adjust the number of bits that you store, you don't have to store the full 32. But, starting simple: This is what the largest 6RD deployment does, in fact the largest IPv6 deployment does today. They operate within a /2846RD, put 32 bits in there and you get /60 for all the residential gateways. 16 sub nets in the home, reasonable. The service provider needs a 27 in order to do this. Because that 28 is being gobbled up completely by the 6RD for the life of the 6RD. After that it could be used for other stuff.

AUDIENCE SPEAKER: Future use.

SPEAKER: Yeah, future use. It can continue. Anyway we'll save that for the mike. But having had a 27 gives you ?? two 28s, one for your 6RD and one for everything else.

Let's try another option. So, /TP?F you want to useless space, you deploy within a /2232. It works exactly the same way in terms of service provider. Except now the home user gets a 64, and why is that bad, right? Still a whole lot of addresses but it's not a whole lot of sub nets, right, it's only one sub?net and that means no routing in the home. It means common features such as at Cisco our routers are nice now valet ones shipped with a home and a guest feature on two different V?LANs by default. That solves an IPv4 with NAT. In IPv6 it becomes more difficult unless you have two separate actual sub nets. Support for 802.15, sensors, all these kind of things, we are getting messages from our forums saying we want to do IPv6 in the home but you know we can't bridge. So you can't think of the home as one big bridge domain now or in the future. And ultimately, if you don't have the sub nets in the home, it's going to lead to IPv6 nag. That's just what's going to happen, right.

So that's not good for the user. So, what about using less than 32 bits? Here is a couple of examples. If your IPv4 space has to be an aggregate, and this particular example is using 10 as the aggregate because in one day in the future you are going to have a CGN and you are going to get a 10 dot address in your home, it actually works with really well for 6RD because it's an aggregate and why carry out that 10 if it's the same? You can still get your unique address by putting the IPv6 prefix, 24 pits and just let all the CEs know that well, stuff that 10 in there before you send the packet over IPv4, right. And the 6RD spec allows this kind of machination, right. Effectively compressing down the 32 bits. With with that, you can give the user a 56 in the home because you are nice and deploy right, within that same 32, the required a 60 before or, you can deploy within a /36 and give the user a 606789 so now you are getting into smaller then default ?? smaller prefix sizes that don't eat up your entire 32.

So that was 10 dot. But what about if you just happen to have lots of aggregates? If you have ?? a handful of aggregates, this example is four, if you can separate your IPv4 aggregates, now you can say all right, with this prefix I'll use this mapping function. With with this prefix I'll use this mapping function. With this prefix I'll use this mapping function and by mapping function I really just mean setting of the N and the M, the variables. There is four values, right. However nothing is for free here.

So we can have multiple 6RD domains N this example, I have got a /12, 16, 14, 11, IPv4 if I did my Matt right that means I am fitting this within a space that's less than ?? that is shorter than 32 bits. I shove in some IPv4, I give the customer 8 bits of sub?net. This is more efficient in terms of IPv6 of course. However, the CEs and different domains require a different value. Remember earlier, it was really nice because every residential gateway you could hard code the thing if you wanted to. Every residential gateway gets the same value. Now it's like this customer gets this value, that customer gets that value etc. It becomes more difficult, not impossible but more difficult. Also remember how we talked about how residential gateway to residential gateway you never cross a boarder relay T follows IPv4 routing perfectly. You separate the domains, to /TKET through the domain to domain, you have to go through the boarder relay thing. I don't want you to have to do that. I want you to have one domain because it's easier.

The multiple domain thing is possible, but it hurts a little bit. And back ?? before I get to this, this is the meat, right. It's not a question of oh, okay, you are going to do 6RD, it hurts a little bit more to do multiple domain so you can fit within your address space, well that's your fault because you are not doing native. It's not that. What my worry is that the service provider will look at that and I'll just give the user a 64, it's easier for me. Once that starts happening the low committees common denominator has been set for the home users and now I can't do my sub?net routing in the home and all this stuff. And NAT creeps in and life gets tough, right. So, it's really that's the forcing function, right. If the ISP has to choose between more work or give the user a 64, I am afraid they might choose give the user a 64. So, how do I get my 27? People have been doing it, they have been doing it in RIPE. People have done it in other regions as well. Well, you kind of lie. You say, you know, I am going to give all my users /48s, all of them. And you run the numbers. And the numbers look like this. You find yourself on this chart and say, you know, I have got 600,000 users and I am growing at 20% over the next 3 years and I can prove that. That means ?? I got 1.2 million users and I am growing at 20%, I'll get a 26. If I got ?? if I am glowing at 0 percent, this column is the same as that column. If I am growing at 0 percent I got half a million users, I'll get a 28. This is the interesting number in terms of ?? the 27 yields a /60 for the home, remember, because you need two 28s, one for 6RD and one for other stuff and the 29 yields a 62 to the home, it gives you four sub nets. That's at least let's me do home, guest and sensor, right, which are the immediate requests. It doesn't let you grow into the wonderful world of hundreds of sub nets in your home. But at least I don't have to do NAT for that.

So, if you are willing to wink, wink, nod nod, I am going to give everybody a 48 and then not, you can go get your 27 if you have more than a million customers. And that's kind of happened. If you have less than 260,000 customers, sorry, you get to keep ?? you are not ?? you might get a 30 or a 31 if you went through this, but you are probably going to stick with your 32, then you have to start doing your domain thing and that's not fair to the little guys. There is two things going on here and I am going to pass on to Jan after this. It's, what about the sort of promise that one day, after I get through all the 6RD I am going to give 48s to everybody and that's my addressing plan and so, give me all that space now. That's part of it, that 48. And the other part is, well, even if we allow that to happen as kind of has been happening, the little guys are getting screwed, right. They don't have the same tools available as the big guys and that doesn't seem fair. So, these are the the issues on the table. And there is possible solutions and I'll pass it over to Jan.

Jan: So the question is do we want to deal with these issues? There are issues out there. They are real. But I am asking you, do we want to deal with these issues or we declare this as a non problem and we just go home? If we think we have to deal with this, we came up with three possible solutions: We removed the first one because it was hilarious by asking IANA to allocate special space for 6RD. Well, the second one would be: Do we want to make 6RD special as a technology, as a transition technology or is this a permanent technology? Because this is not going away. People will do this. But if we make 6RD special and allocate from, I don't know, far end of RIR allocation the v6 space, we need to reclaim it back then after three years or six years or ten years, whatever time we set. And, there is third possible solution, that we rise the minimalcation size for IPv6 space to /29 and make all the little guys happy, because if they don't qualify today for more than /32, they would get /29 by default and not easily, but fairly easily, be able to deploy 6RD and this way we don't make any technology special. So we don't have to reclaim space back. So we don't waist the resources on reclaiming space back.

So, we would be happy to hear from you if we have to deal with with this or not. If you think this is an important issue or not, and we would like to hear about other possible solutions or suggestions, how to make a policy ?? make policy work with this transition technology that we are going to see.

Suggestions? I hope you guys have suggestions, not questions, because we cast most of the questions. Thanks.

CHAIR: Okay. Thanks for very clearly explaining how this is working, how the multi?domain stuff is working, where the sore spots are. Thanks for bringing up the question and I am just running into the coffee break now to have a bit of feedback from the room. Please bear with us.

AUDIENCE SPEAKER: My name is /APBG Vincent. This is a real problem for us. We have a /32 we are a little guy and we need to do stuff like mark explained, that I wouldn't like to do that because it makes the thing painful. So I am ready for doing a /29. There are enough resources. There are no problems doing this for the foreseeable future and I would be really happy to get this fixed so I can even more easily do IPv6 to my customers, at least in my legacy network, so thank you. Towns so that was a vote for number 3.

CHAIR: There is no voteing in Address Policy. That was a voice.

AUDIENCE SPEAKER: Although you don't want to hear questions, I still have one because it's a technical one. Did I get it right that you would actually need two /29s, one for the 6RD and another one if you want to deploy IPv6 natively, is this correct?


MARK TOWNSLEY: No, no, sorry, not two ?? you would need two 30s, one for 6RD and one for other stuff which makes up the 29. So, a /30 ??


RUEDIGER VOLK: With the /30 you could stiff give 2 bits, you could still give 2 bits or 4 bits for the sub?net.



MARK TOWNSLEY: Yes, a /27 yields a 60 for the home and that's actually what's commonplace amongst the few million and up carriers. /29 yields a /62. Because there are two 29s here and you actually working the 6RD within the ?? two 30s here within one of the 30s.

AUDIENCE SPEAKER: Can you please bring back the last slide? I think that 2 is the most reasonable choice. It gives a guarantee to RIPE NCC to reclaim back any prefix which was on purpose for 6RD and it doesn't apply any longer when the ISP goes for native IPv6 and I don't think 3 is really saving resources because it's a waste by default for many, many ISPs who don't even need more than /30 or /31, and do add to that also, the migration for all others who have got /32 and who just ask to extend it to /29, and remember the /35s which we are back to, /32 and the migration is still not there and it's ?? so, I don't think you are saving resources to give, by default, the /29. It's a waste by default and I don't think that there will be a huge demand for /27s to accommodate for 6 are RD deployment. That's for me the most reasonable choice: 2.

Jan: So for the minimalcation sites a /29. Currently a /32s have been allocated with a reserve space of /29. So, we can easily extend the legacy IPv6 allocation to say /29, all of them.

AUDIENCE SPEAKER: Yes, but why do it when ??

Jan: That space is there and it will be never be used because it's reserved for those LIRs to extend.

CHAIR: Let's not start arguing that point right now. We are running a bit short of time. Something I want to point out here is any sort of temporary policy, we tried that in the past with the PI policy to come up with criteria under which to determine that a certain technical need has ended and something should be with withdrawn. We have discussed this for a long time and at that point in time, we have decided that we are not able to actually find criteria that something is over now. So, that's a specific rat hole that we need to consider very well. On the other side, I have done a bit of Matt and we have something like 7000 LIRs in the RIPE region right now and we have one 30 thousand /29s, so that waste would sort of like be possible. I am not saying any solution is the best one, I am just pointing out numbers and problems we have had in the past. Shane, then pen /TKEUBGT.

AUDIENCE SPEAKER: Shane Kerr: I guess like that's good that you did those numbers because I guess that would be my racks to this whole proposal is (re action) conservation is not really that important here and allowing a /29 seems for straightforward. Have we in the past had technology specific Address Policies? I thought that was kind of resisted in general /O

GERT DOERING: There was some talk about cable and things in the policy. Most of time which will thread has stood up and said we should not have policies that cover specific technologies because other technologies might evolve that also benefit from addresses. So, it has been mentioned but usually not very ?? not taken up very well.

SHANE KERR: I think that's a good general guideline. And you are going to kind of picking a winner if you do that too. Everyone is going to get for 6RD no matter what their requirements are once that's the way you get space.

AUDIENCE SPEAKER: Benedict: First of all IPv6 is not IPv4 so wasting addresses might actually be a good idea at this point. That was one thing.

Secondly, what do we want to achieve? Our goal should be to make people deploy IPv6 as soon as possible and we should make that as easy as possible. On the other hand, we don't want to build?up another legacy, pile of legacy technology sort of things and the easiest way to dealing with that is (technology) to, how should I put that? To keep the functionality reasonably low so people have a reason to move forward to proper IPv6 later on. If we give our customers a slash 62, each of them, they will have some reason to eventually move on to real IPv6 and we are not stuck with 6RD for the next 20 years or so. There will be some who say well this is good enough for me, but it will not affect us to the point that provider say, hey, we give them 6RD and that's all they want anyway and we are not going to do the rest of the job. So I am pretty much in favour of solution 3.

CHAIR: Okay, two more voices. Then I am going to wrap?up.

AUDIENCE SPEAKER: I think I am fine with either 2 or 3. I just have a clarifying question on approach number 2. So if there is a policy like this, would you have some conditions related to that policy as it seems that like, if you are running on net 10 space, you don't actually need any special allocation, or if you have an aggregated block, you don't need it in this case either. Would you apply these kinds of conditions in the future policy or not?

CHAIR: That's actually the kind of problem space that you run into. So to actually be able to define criteria where that applies and when that stops applying is hard.

Jan: And if the RS P goes off 6RD and do some native stuff in that space, how do we reclaim it back?

AUDIENCE SPEAKER: Well the questions of allocating space for someone and then reclaiming that space, I think those are are separate, and we can discuss what the reasons are for making an allocation and then we can have another discussion on whether it's ever possible to reclaim. I was only talking about the former, the allocation action.

Jan Jan but I think they are tied together somehow, because in the second option, then we must reclaim the space back, because it's a special case, we make it special. Hence I am not in favour of that.

AUDIENCE SPEAKER: I am not in favour, and I think this has been clear since several years, of any temporary policy. I think that's not the way. Even if myself tries it sometimes, would I realise that it's not something we can reclaim any results afterwards. It is not going to work.

There is a single reason I don't like 6RD. And the reason I don't like 6RD is because I believe using 6RD with existing policies will bring customers a single sub?net. If we change that, I am very, very in favour of 6RD. So my suggestion is not doing anything like this, but actually making sure that we make the policies flexible because we have enough IPv6 space and we need IPv6 now to make sure that if an ISP want to deploy a /48 and that means needs a /16, can get a /16. If they can use a lower number of bits instead of 32 bits, for example, 16 or 24 bits, they will need a /24. That's not really that bad. I really think that there are more important principles in IPv6 and the first one is deploying IPv6 as soon as possible than really ultra conserving a space that we are never going to use at all because we are not going to use IPv6 in the next 400 years.


MARK TOWNSLEY: I want to clarify what you are saying is that, if I understand you, it's really number 2, that e.g. means example /27. In your case you are saying special, you know, if you needed 6RD to deploy and you want to give your customers a /56, okay, 24.

AUDIENCE SPEAKER: I don't think a special policy. I think making sure the existing policy works for 6RD and other technologies that may be in the same situation. It has been said before and I agree, a special policy for special technologies don't work very well. So nothing special, just actual policy making sure it works for any ISP willing to deploy 6RD and willing to deploy it this way.

CHAIR: Okay. I don't think we actually have enough /16s to do that. Nevertheless, thanks for that view. I see Lorenzo standing there. I think that's the very, very last comment. There is Eric behind him.

AUDIENCE SPEAKER: Lorenzo: So to the earlier point, I do partly agree with /KWRORDey, that maybe we can just work around this by clarifying the existing policy that if an ISP justifies a larger allocation based on the use of 6 are RD, then the community believes that this is a worthy goal and therefore should be taken into account by registration services when allocating space, right. We can just make sure that the existing policy allows RS to say, yes, in this specific case. I am kind of wary to say we should allow any new transition mechanism because otherwise I will make up my own transition mechanism that requires a /16 and RS will have to say well we don't really like that. So it's good to clarify that.

In particular, I don't want to be doing this thing again. This is a very painful transition for the industry as a whole. We might not even make it. And we are in this position because, you know, 32 bits should have been enough for everybody right, and it turns out that they weren't. So, I do think that we should try to conserve where it's reasonable, okay. So two points really.

Let's try to conserve where it's reasonable. I think, I don't think anyone in this room and probably on the mailing list will disagree that it's reasonable to provide is access ?? /TKHR?RB 27, I don't think a we object host error data operating centre should say we need to do are 6RD so we need a /27. I think we should just sort of clarify that and not assign separate space for this. Just say well, you know, if you are using 6RD then you get a bigger allocation and it's, you know, if you provide a plan that makes sense, then we'll ?? just like we do when we normally deal with requests.


MARK TOWNSLEY: That sounds like some version of number 2.

AUDIENCE SPEAKER: Yes, but not a ball can eyed address block. Just a 6RD. We say that we as a community is a useful tool. We will you know approve stuff that requires a /27 when access IP wants to use T I think that's a fair policy.

Jan Jan I wonder how many traffic is there from 6RD?



AUDIENCE SPEAKER: It's the only access network that uses it on large scale. It's basically the toeality of the of RD deployment at any scale. I don't think anyone disagrees that it's a worthy technology. I think Eric wanted to say let's take back 3 FF E from IANA and tut it in there. So, that's another suggestion as well.

CHAIR: Very, very last comment.

AUDIENCE SPEAKER: I just thought about the thing that we shouldn't make policies that, special policies for special technologies. But I would like to turn that around. We shouldn't make policies that prevent good technologies.

CHAIR: Thanks. I think that's a very good closing word. It's actually ??



MARK TOWNSLEY: I have one question for you Gert. What should we do next?

CHAIR: That's what I was trying to get at.

Jan: Can we have some input from NCC stuff

CHAIR: What you guys need to do is work with the Working Group Chairs with Emilio and possibly Alex from the NCC, whom, you know, on drafting something that is then sent out to the mailing list, and then we get input from the mailing lists, form a policy document and be done with it. So, the draft should be something that everybody agrees on, that makes things a lot easier.


MARK TOWNSLEY: I am hearing voices of 2 and 3. So, we should, you know, kind of maybe clarify 2 and clarify 3 and initiate discussion on which is better?

CHAIR: I think we should just look at the policy documents and see how we can sort of make this fit together. Voices from this room tend to give input, but can be usually convinced to accept the other option if that's more reasonable and ??

Jan: For option 3, it's easy, we just ??

CHAIR: We don't discuss it here. Stop. For now we just had input. We have an amazing number of people have been with us through the coffee break, which is now nearly over. I thank you all very much for coming here and giving us feedback how to go along. Thank you to the scribes. Thank you to the stenographers. Thanks to the audio video guys. Everybody who helped making this work out. Enjoy the rest of your coffee break and see you in Vienna.