Internet Engineering Task Force 103, 5 Nov 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF103-V6OPS-20181105-0900

Description

V6OPS meeting session at IETF103
2018/11/05 0900

https://datatracker.ietf.org/meeting/103/proceedings/

A

B

A

B

Yeah, it does everything except load. My presentations.

B

So I come on this. You know I'll go ahead and.

C

B

B

This doesn't get me if I go to the agenda and I say fine, you know I. Can this is my agenda? This is my Charter. This is a map.

D

Okay, except that powerful I'm, going to run that video.

E

B

Okay, so I actually want to run it as all importance. Oh.

E

B

Need you run it as.

C

Nobody's dinged me about submitting my slides as PDFs. Powerpoint is just fine yeah.

F

Well, you have to do yeah.

B

I'll do this? Okay! Thank you.

F

B

Doesn't work on my computer? Oh.

F

B

Yeah I'll get there but I'll show my dentist.

B

Okay, so it's 903.

G

B

So it's 903 you're, looking at the agenda that we have posted today, Ron and I have a couple of questions we need to deal with and then we'll move directly into this thing.

B

But is there any bashing that people want to do to the agenda? Do I need to change the agenda in any way, seeing none, okay, so two questions one between I, ATF's, 101 and 102, and then I, atf, 102 and 103. We put out a question every week or roughly every every week saying. Let's take a look at a draft and comment on it. Our perception is that that work has worked reasonably well, that people have looked at the drafts.

B

They've found the load acceptable and we've gotten comments on a variety of drafts and in at least one case, we discovered that their working group wanted to adopt a draft and we hadn't figured that out, and so that became clear and we adopted a draft but I'd like your opinion, because I I've just gotten kind of a few comments here and there as a working group. What do you think about that process? Is that working for? You is that helpful. Is that something you want to do.

C

Raise your hand if, yes,.

B

Okay, I see a lot of yes raise your hand if No, okay, we'll continue doing it. Okay, second thing: I'm gonna turn over you.

C

Okay and we have a draft PD Hosts that has been kind of flailing looking for working group and adoption or not I have two questions about that draft. First, raise your hand if you are familiar with Fred temple ins, PD, host draft.

C

Okay of the people who are familiar with it, how many think that it should be a working group item one? How many think it should not be a working group item, one two: three: four: five: okay.

C

Would you like to make your consensus call Warren.

C

H

C

Not working walking to the mic: are you working to the night? No? Okay? Okay, so what I think we have an answer.

H

C

There was one person: do you want to speak in defense? uh No okay, so we can move into the agenda. Okay, cool.

B

And with that we're gonna switch to the other laptop.

B

Shelley shingly.

I

So good morning, this is about the China educational research, Network ipv6-only practice, including backhoe servers, cries and ipv4 as a service.

I

Okay, then that's the outline of my plantation. So actually we have a tree or backbones China education, the research network. Why is caught sir net? It started in 1994 and I, it's ipv4.

I

Currently we have 38 hops and about more than 2,000 the universities and another project has started in the year 204, which is called Serna to actually the interests is seeing is here. It is ipv6 only studying from to all four and the currently. There are 25 hops and about 1,000 the university's connected. So you can see they're separate backbones and the highway starts ernet to design. Then, actually there several questions we asked ourselves.

I

The first should we start using do stack our ipv6 only and the decision is ipv6 only in 204 I will give you reasons later and also we have some kind of promotion strategy. Basically, it's high performance in there free another. Another thing is the security because ipv4 their nets and we sought the ipv6, because there is no net six six then properly. We can restart the end-to-end security and that's the thing we caught salsa address, validation, architecture and we work in IETF.

I

Let her into the savvy working groups, that's for the first hops and then we talked about. We sought the transition and actually because that's the ipv6 only backbone. So we thought we can do things update so ipv4 over ipv6.

I

At that time, also we thought, probably before in a v6, should talk directly through some kind of translator, then that actually we working I if behave software and this group we six ops, so the promotion strategy and the plan is for performance for CERN at its ipv4, and it is because there 2000 the universities connected in congested, however Serna to its ipv6 only and its light loaded, at least from the beginning, so high performance for ipv6 and other things.

I

Actually, even we are academic network, but we do not have operation fees from the government at the university professors in the students pay the connection fee. So that's some kind of sharing model, so ipv4 is not free, Anderson I to ipv6 Tinley, it is free. So actually was the promotion slogan we told to our members is: if you want use free and high performance network, then please use ipv6. So that's the way we promote from the beginning and tell you the truth.

I

It's quite a success for, because about half on ok, the ipv6 to ipv4 traffic ratio is 50% is all like.

I

However, in reality we sought can we turn off sir net ipv4 for a single day and the see if the users still satisfied with our network and service? No, so the users need to communicate with the ipv4 internet. Even the network is somehow congested and the not free. So that's why we move in this direction and the solar sings. That's a summary for security as Sabah and the Saudis asada are cease related in in the savvy working group, mostly savvy working group and ok for sir net some tempers networks.

I

Actually we actually deploy savvy technology so make the sauce trace possible and the most secure, so that's C and the for transition. Actually, that's a brief history, starting from 1994, that's ipv4, sir net and the in the year 1998. Actually we start to connect to six pool and uh that's ipv6 over ipv4. The reason we realize we need to work on IP v6 is in China email in China. They are 320 million students.

I

Definitely we cannot get enough ipv4 just from a beanie and they in the year 2000 we tried you stack, which is called Natural, Science, Foundation, Network and the later, as I mentioned earlier in 200 we start ipv6-only signature. Then we thought we can do innovation so as ipv4 over ipv6, because as ipv6 only backbone. That's turning to the ITF software working group and the later we work in the behaved working group.

I

That's translation, Staley's translation and we call avi because in Roman replantation IV means 4 v I mean six, so I by actually means four and the six can talk and the later we realize there is some application, embed, ipv4 literals and some applications ipv4 only so we saw two probably can do double translations. So that's the boy that we call that and because it's something for 64 issues and by that time, actually behaved working group clothes that he cleared of victory.

I

So we move back to the software and then later we realize actually double translation and they in cabaret. She is something quite similar, so that's into the outcome, after RFC SMAP, t and map. So that's the story for our experience, so those other related RFC's and the for single translation in the ipv4 as a service actually color mark the blue are the RFC's. Actually we deployed in the siRNA to backbone. So that's basically the same. So currently that's the situation. We have two backbones cern at ipv4 and the siRNA to ipv6.

I

Actually, we have multiple stylus translators deployed between cern at ipv4 and ipv6. The reason we can do multiple, because that's one-to-one translation that stateless, so no matter was.

I

Trafficking, one direction can go back to the other address family in another year: translator because it's tailless just like in a BGP, lo, the balancing states and then actually, we have ipv6 only servers distributed in different universities who connected to Sena to also their ipv6. Only clients are ipv4 as a service clients distributed in different universities, wire second translators.

I

So the the first translator or the core translator are the same Staley's one-to-one mapping between before and the v6 and the depending on the the hosts are and the systems either as a single translation or double translation, or even some kind of encapsulation or not in this case, no interpretation, just the translation. So there that's the same and okay again talk a little bit of backbone because so near to is a ipv6 only backbone. So certain Aitu has its own address blocks, lat, / 32 and the some converts networks have their own provider.

I

Independent ipv6 address block so BGP connected to those universities and if inside the /, 32 sir netted, then that's static route and the link speed is 2.5 g Kenji and 100 G IDPs, OSPF, purchaser and the BGP. That's IBT PAE, BGP whatever and then another thing I'd like to mention is multicast. We run SSM in the sauna backbone and actually the restriction is the user cannot use their own / 48 as the SSL sauce, but instead we assign a special as the sausages of SSM. That's a better security control. Another thing is the unicast.

I

Actually, the routing accepted link change of those kinds of his static. However multicast it's depending on the join the situation as install that route are not install and that make security and the scalability or whatever performance is some kind of disaster, so actually because as SSM, so it's predefined, so we have static, join for the groups, so the whole sir net to back boom ipv6 SS is static, not a dynamic for multicast. So that's the same and further.

I

Actually there, the truthful Serna to ipv6 only backbone, the routing, and we are thinking we should try SR v6, but not yet we're looking for that and the translation, as I mentioned, a stainless translation and the encapsulation and the SSL so that those kinda C and some kind of sauce address validation beyond the first half so that Sava and because there are multiple prefix.

I

So we try to define some kind of controller to control the prefix so make some kind of Sdn drive and for the first hub or for the end users as DLC, p, ra and sorry. So that's basically the structure in the backbone and the ipv6 only servers. So actually we deploy ipv6. Only servers with the ipv6 address is based on RFC 60 50, so the ipv4 address directly embedded into ipv6 address.

I

So if the the user connected to this server using ipv6 that's connected directly, if that so ipv4, actually that the user sees the ipv4 address but actually is translate to that ipv6 and because it's stainless so actually we is more people. Translators can be used to do load. Balancing of those can see- and so currently we have four 10g translators as all can cast it, but the performance still relatively: ok, ok and the ipv6 only clients, that's the interesting, say: ok for the partial function.

I

Ok, that means if your application is ipv6 and no ipv4 letters embedded into that, then actually support a lot of operating systems and the last th CPV. Ok, ok, I, repeat again: for the clients, there are two kinds of clients: wine clients can support. The dhcpv6 stateful, except Android. Most of the operating system can do that. Another is the cannot support IP dhcpv6, that's mainly Android in Windows XP, for example. So so those two things and we have two SSIDs or Wireless.

I

Why is for is the pv6 state for another- is in C just are a switch the rbass, so that's the ipv6 on it. That's the one dear he mentioned to look at the problem. Another direction is ok if, for example, the iOS and Android with 464xlat they're, actually even their ipv4 later O's embedded our IP, then still you can use that. So this we call the full function.

I

Support of the ipv6 and the partial function supporter is okay, if the webpage, which yes, no problem, because the s-64 where you can access those kind of information, however, if ipv4 later horse embedded UI are.

B

Still, you cannot.

I

Be a fail, they seem either safe and.

B

By doing before, you move on okay, I'm guessing the Jordy. Has this question in his mind, he's asked a number of times when we talk about ipv6 only. What do we mean? Do you mean here that you're only giving the client an ipv6 address it doesn't? There is no idea before there at all, isn't.

J

That the definition you know yes so.

B

Jordy, do you have more any question there.

J

My my point is: that is not that simple as that, when, when you say a network is ipv6 only if there is some ipv4 function, even if he's at the end of the upstreams, let's say you are translating so that network is not ipv6 only. My my my my belief is that we need to start speaking about when we say ipv6 only with specific part of the network. We are talking about it's the lands. It's the access is the core.

J

It's the app streams, I think that's the only way to really have a clear picture for everyone that that's that's the thing.

I

I agree: okay, actually here I mention I, think v6 at least ipv6 only subnet. It says answer your question right, so ipv6 only subnet, okay, actually a little bit more complicated, that's to the subnet side and the truth application said. Actually there are two cases, for example, iOS as single translation, so to the application. Socket is still ipv6 only, however, for enjoyed that the probably four six four X later actually to the socket function. That's use that, however, the sub thank you and analysis for legacy. Yes, one.

K

Question Bob hinden, so over in six-man, we're working on this ipv6 only flag. Things though Ras can the administrator can tell, can use that to tell all the hosts only use v6. Is this something that's useful to you? Have you looked at this.

K

So in six-man, there's a draft about having the administrator inform all the hosts to only use v6 did not turn off the four. Is this something that would be useful to you.

I

K

Okay, well, please come to six-man and say that okay.

I

Thank you: okay, like okay, four, six, four X ladies deployed in the operating systems. If for the legacy, applications are owed, OS, which is ipv4 only then actually we deploy a translator in the same second translator, so that subnet is use that, however, the upper stream, so that's another se and friendly speaking actually at our campus networks, we have two SSIDs. Why is IP V still only subnet another? Is you stack subnet, however? The upper stream Arkham's ipv6 only.

I

Okay, another thing actually type II, so actually this is also ipv4 as a service, so the upper stream is ipv6 only but the subnet is you stack and then the same. Actually, this friday is for high performance computing ipv4 as a service, and actually you may know there are some top super computers located being russia city, like jump supremacy in china, middle of China China. However, some university, for example, my University, the bio research center use that computational facility and that the data is about like one tea per day or those kind of see.

I

So actually we use double translation to provide this kind of service. The reason for that is actually in this case the ipv4 address, is private, address, not the public. Yes, so that means 404 to build a VPN. So that's situation and the the consideration for this is, and the network can be fine-tuned using ipv6 prefix so that those ipv4 the physics prophets can be put into a higher priority through traffic engineering, so more flexible in the controllable than ipv4 PDP and the more cost effective than MPLS and then- and there were network operation.

I

Amendments very simple and to end address transparency, no in calculation decapitation is required a for example. If the network operator try to take the traffic and reducing if it's in calculation, eternally, then the first IP address you'll see is the eternal address not end-user. Yes, however, for double translation, the ipv6 address in bad before so you'll see different end user has different addresses and the no need to activate application at this stage, so the user still use ipv4 as the application, and one thing quite interesting for us is the different charging model can be applied.

I

Why are you friend I pv 6 previous? So because I mentioned earlier, they you professors, sharing I, mean paid the fees for using the internet. However, for this, what actually they can have unlimited usage and that also make the tempers network administrator life is much easier. So there are some interesting discussion since that's our observe the filly for ipv4 as a service, either use inhabitable, Asia, double translation and the way play. We prefer the bow translation, because the turbo translation can reduce to single translation and eventually as ipv6.

I

Only, however, in Kappa later you need to keep two points and also the traffic engineering, as I mentioned, I have a thicker meter to show that and a second, the staleys are stateful, because stainless can restart entry and address transparency and there's much more easier for scalability as skill. So, if possible, try stainless and the RFC 1650 to address all other mapping abuse and the way belief there, the IDC map, you know those kind see we believe we should make the the why the people take a look at the wire know.

I

What's the IP before literacy bed is so make it as transparent as possible and the same crate, ipv6 prefix for the sauce in the destination or befriend ipv6 address in RFC 1652? Actually, it says you should use. You should use the same prefix and, however, that can retail okay actually same prefix can result in the optimal route him. However, if you have two administrative domains, then probably the only choice use different of prefix and finally for the clients here, CP v6r snack.

I

Actually, we like dhcpv6, unfortunately enjoy the cannot support us. So we have not no choice. We need to support slack, so there are some reasons right, because this is quite interesting from I. Can the ipv6 address protector and the GPD and me you can see the high GDP our demand countries. Ipv6 is quite good, however, for the last about put our developing countries, there is no ipv6.

I

So probably the ipv4 exists for details on many details and if we want eventually get an ipv6 only then we need to deploy translator in some place of the Internet to keep a single engine and well. This is actually I said in the wire. The operator can take. Look at the ipv6 address without a declaration to do a CR or traffic control rate limiting. However, if that's turning in technology, you can not do that directly using the existing. So you have to do the calculation and they make sure the traffic.

L

I

You give me all the traffic in that provided by that Turner point also, the end window just transpose I mentioned so on the wire we know across the ipv4 address, embedded that we can do a better and that's the optimal routing. So if it's the same prefix, then no matter the ipv4 is used in ipv6 or I. Translate it in ipv6 are in original no problem. The longer is the prefix match to automatically redirect your traffic into the right place.

I

However, if different projects, then you need to do whatever here being all those kind of seeds and though I could certainly support, as I mentioned, the full function so for for iOS, 9.2 and above in the Mac OS 10 point 13 above in the 464xlat Android. Actually, that's quite quite good, like originally for six for explained, supported the LTE interface, but currently about 6.0. The W dentists, support soils very good and now I heard the Windows 10 can support. However, the Home Edition we try to have not, but eventually that.

L

I

Supported that's a very good news. However, one thing is: if you want sled, you have to be very careful because Windows 7 cannot support our DSS. That's the problem. I don't know, Microsoft can have upgrades attack attached. That will be great. So finally, because our theory is IP pics only with single translation, if you can ipv4 as a service with double translation information, if you should and the do step and if you must and the way to ipv6 only as for as a service ipv6 only with single translation and they eventually ipv6 only so.

I

Thank you very much any questions.

M

Hi there, my name is Natalie I noticed you are using an interesting prefix for your network, its 2001.

M

Da8, I think it's very close to the documentation prefix, which is 2001 DB 8. Actually, that's the real sir net to prefix. Yes, also, surprise exactly did you ever have.

I

Any issues with that: oh okay, okay, fine, maybe some mistake; they thought so now to actually we're using document. Oh yes! Okay! Now! Yes, maybe.

N

Lorenzo quiddity, I wanted to ask you what what mechanism used to discover the nat64 prefix in the host, as you mentioned, RFC 70, fixed fee, and also you mentioned this table in 60 52, which has got different clanks and suffixes.

N

But I know that the 70/50 implementation in Android only sports, 96's yeah.

I

So in that case, we so.

N

Used our size 26, do you see any reason not to use slash, 96, okay,.

I

Actually, that's that's a very good question. We actually prefer some kind of Spanish translation. So if we want to use just representation defined in like map t, then actually we can not use the slash 36 in that case. Actually the compromise is the salsa. Yes, that's the map, t format. However, it's the nature of gasses laughs so.

N

Okay, so right now you can't do right now you can only do 96, but you would like to do something different sure.

I

I

N

That will be great well. Actually, the reason I ask is the six men we're talking about deprecating everything else so.

N

I

Are practice, then, we use different.

I

Route unless the trade off I see I cannot see you. Why not? Why not use other prefix lens rather than 96, because that says 1750 then.

N

There's a draft in six-man later a little later this week, we're presenting the reason for not supporting it is that it would make the option 50% bigger in the RA there's no space for prefix length if you want it to fit in 16 bytes, and so maybe you want to might want to comment on that, because we're not aware of any implementation that supports it actually I think the iOS implementation does support it. Did you did you? Did you verify that I OS supports non /, 96 yeah? It does no.

I

N

I

That's not what.

N

David told me he wrote it, but clearly yes, all right. Thank you.

B

Well, not shingling. Let me comment on that when you started building ivi, which was 2008. Something like that. Your argument for the way you structured the address was that you wanted to straddle the ipv4 address across bit, 64, so that you could use ipv6 routing to take traffic to different places and have multiple hosts in a given place. But but basically it became a routing game. Are you still doing that in ivi yeah? Yes,.

I

B

You are not using a 96, you are using a yeah.

I

40 years 48 yeah.

B

I

The exam bar gave me still using 40, not changed. Okay, those.

O

I

The nice is slash 24, ipv4 subnetting, equivalent to a / 60 for some reason: yeah yeah.

B

So an additional comment there then Lorenzo is that they are using it in a way that they use routing within the siRNA to network based on parts of the ipv4 address.

I

Action, our pin is we at some stage into ipv6 and a turn-off okay.

B

Okay, so thank you very much. I, don't see anybody else at the mic, so I'm assuming we're done. Okay, Jordi.

B

Hang on a second mortgage come so.

J

Okay, so the the first document I am presenting today is the nat64 4 6 4 X lab deployment guidelines.

J

The the region of this document was a discussion that we had in the in the ATF mailing list about setting up the network, which not 64 only and then while I was saying, there are applications that unfortunately still use literals or all sockets, and that means that that that will not work for for everyone and then I think it was Christine and Emma was suggesting the mistake with it basically was using dns64 and and then I started to work in a document which deployment guidelines for 4 6 4x lat explaining what are the consequences if we don't use dns64, and then there was a suggestion from the working group regarding that document to instead of working in just the 4 6 4x lat working in a general deployment guidelines for any nat64 usage.

J

So that's that's what we have at the document today across the different versions of the document. I got sometimes questions like if the document is just talking about NASA 64 as a preferred transition mechanism that that's not the thing. What I am NOT suggesting in the document is. This is the way to go. What I am saying is: if you already decided to go to not 64, then this is the way you can deploy it, not not just to discussion.

J

That's another question I got frequently is not just a discussion about God are the things that dns64 breaks with the intersect, it's one of the important things, but it's not the only one okay. So the starting point for the document is. There are three main issues which deploying necessity for one of one of those is, if you are using the unassisted for it, may break the intersect.

J

The recent work from Jen that was talking about 1.7% I, believe that was about two years ago, I, guess that will increase if the penetration of the deployment of Gianna SEC were gross. Obviously the other thing is the using just nat64.

J

There are applications that use literals or api's that, of course, they are not going to work on that situation and, of course, if you happen at work with just not 64 and you have still all devices or applications that use IP before only they will not work. So that's that's meaning that in some scenarios you cannot just survive with nat64 alone right.

J

When the DNS system for document was published, there were a few scenarios, work it out in that document and from the perspective of an operator today, I believe there are much more scenarios and I have done a classification of those scenarios in a scenarios that are known to work and those that will work only in a special circumstances which are still valid, but not the generic case. So for the scenarios not to work, there are for possible scenarios or super scenarios where you have an internal or outsourced nat64.

J

Dns64 combination. Okay, so that's that's the first set of a scenarios. Then there are three additional scenarios where you are using for six Forex lat and either you have an internal or obtuseness sista for dns64 combination and then two more possible super scenarios where you have four six Forex lat, but in this case, without using DNS 64 and again, you have the necessity for functionality inside the network or outside the network known to work in a special circumstances.

J

There is when a scenario which is not 64 without dns64, another scenario which is dns64 in the ipv6 host, which is something that more and more operating systems are already including. So it's it's something that maybe today is not the optimal situation, but it may change in the future, and then service provider with the NAT 64 and the dns64 is in the remote only network.

J

It seems that this this scenario don't makes too much sense, because if you have at the NS 64 in the remote network, they logic thing is to have actually those remote that remote network is already a pv6 right, but it may happen. I am trying to do a very quick comparison about these twelve scenarios. At the end we come to 12,000 areas, and this compression is based in four specific questions. The first one is: are the hosts in that network validating the intersect? The second one is: are the hosts using literal or api's?

J

The third one is: there are any ipv4 on the hosts and the last one is any chance. The user can change. The DNS I call this foreign dns, because that may break some things that the operator is considering. So, for example, if the operator is providing a dns64, but the user is changing the DNS, then of course the DNS system for function is not working.

J

So I am writing each of these items, depending if they are good or bad in each of the possible scenarios, and then I come to this to this table right I have additional sections looking at them very quickly. There is a section regarding the DNS SEC considerations and possible approaches.

J

Discussing one of the possibilities is not using a dns64. The other one is the dns evaluator aware of dns64 estoppel editors silat with DNS proxy and validator ACL of clients, mapping out ipv4 addresses and then considerations regarding dns, reverse mapping, then the usage of forces for X, let which or without the end of 64 explaining what are the differences of one case and the other a manual configuration of pouring the DNS again, is when the user is able to change the DNS configuration.

J

So that means that the DNS functionality is not under the control of the operator anymore, DNS privacy, because that's another thing that get broken when you are using DNS 64 together with privacy, you are not controlling using the DNS system for probably a split DNS. It's another possible case where the dns64 may be not working comparison between using a well-known prefix or a specific network.

J

Prefix considerations regarding the item for literals and all api's ipv4 only host and applications and considerations regarding the salaat translation, then I am doing a summary of all the considerations and explaining also that the document is not just talking about operator networks, because in most of the cases, all the the durations will be the same.

J

If you are an enterprise headquarter, you are trying to use nat64 in that network, so basically it makes no difference and then it was I think it was suggested by my fret to include an example of broadband deployment which forces Forex, lat and also seal at implementation and I'm, not really sure that that will be possible. But there was also suggesting a suggestion to include some benchmarking and I.

J

Think that was that was it so questions, because one of the problems I I am having is that, since probably two months or so, I am NOT getting inputs for the document? So even if this document was adopted, as a working group item is still useful, is somebody interested in contributing or saying something? I don't know? Jenn.

P

Jenn : I feel a bit guilty because I promised you to read this when I was a monorail and I actually finally did and I my feeling is: it's probably my simplify the document slightly, because I found that it might add my impression that in many cases you might actually just combine a number of scenarios.

P

In one scenario, for example, saying you have not six four, you have dinner six four and it really doesn't matter where dns64 is located because I think currently it's a few different scenarios, which makes the document probably way too long, because I actually was struggling finish and originate because I found too many similar scenarios and you need to sit down what's the difference between them. Actually, so it would be my suggestion to scientific to see if you can slightly simplified.

P

Also margin from NICTA said just recently did more measurements on dns64 and ipv6, similar to what I did a couple of years ago and percent they look quite similar. I can send you link, but it's not in unfortunately, the same I need to use. Google, Translate, sorry, I, said consumer format. Again, as I said, my suggestion would be to review how you make it more readable at.

J

The beginning I was used, I was having lesser scenarios and actually I got the input that I should describe more more of them there. The reality is that I agree. There are some scenarios which are very similar, but this is not actually making the document longer, because if you look at the length of that part is because the pictures- so it's not like you- need to read a lot of more things is because each picture they have four page.

J

Okay, so I, don't think that's increasing the complexity of the document, but I thing is providing clarity. If you see a picture, it's very easy. You don't need to read the text, because the text is basically not saying anything different, but you have been one case, for example, four scenarios and looking at the picture, you get the idea about all of them and then the text says all these four are the same. Okay,.

P

Probably yeah because I got an impression that I'm reading a lot of similar text, saying it's exactly the same scenario above and then another couple of section of text. So again it might be just me being like I.

J

Can't take a look again and try to squeeze a little bit the text, but for clarity, I think it was that way, and that goes the suggestion. I got before so so. I agree, we'll have different views and some people will say it's too long and some others will say is too short. Please terrify it and some people were suggesting even additional scenarios, which I don't think we need. We need them right.

B

So, general, let me ask your question: you were on the hook to do a review of the document. Are you still gonna do that? Thank you. Thank you.

H

So Warren Kumari summary: my comment is only slightly related to this, but I didn't think of it earlier. So I wanted to announce it now. So Stuart Cheshire has a document which adds the ipv4 only darpa name to a registry.

H

You know and you're talking about EMS things, florists I figured I should mention it now yeah, so the did the ipv4 only dot.

H

Arpa name was never actually added to the special use domain names registry, and so this is more admin stuff, but anyway, he's got a document that does that it's kind of related to v6 ups I've agreed to ad sponsor it because DNS up said there looks like admin stuff, not interested, so I will see, see the list when I actually start that if people can review it by using no P no comments, you comment it I.

J

Think I commented on that and I have I believe I have I mention in the in my document about that. So, in fact, in my IANA considerations in this document, I am saying: if this is not done, we need to do an errata and, and so on, so I have I have to split it text. For that. Thank you.

B

Okay, any other comments.

B

So it sounds like we're really not ready to close up on this documents until you get Jen to review- and you know whatever comes out of that, so what I'll do is in in our list of documents going forward, then I'll ask for people to comment on the document. So it's again, your review will be very helpful.

J

And this fight that there are some some of labor room. So if people believe it's interesting, we sit down together to speak about this document. I am happy to to try to set up some time, for that may be an option right.

B

Okay, so now surely you're also, yes, okay,.

J

So what what happened here is this document is started as two different documents. The older one is is the sunset ipv6 document. Unfortunately, there were very very few comments on that document and then sunset is sleeping. So so there is nothing to do that and and Cameron from D Mobile was sending another document and I think it was somehow fretful that fred was suggesting to merge. Cameron document with the previous document I have presented, and my comment was: no, it don't make sense.

J

I mean those two documents don't work together, but then I realized that the ideal thing will be to match these two documents and I talked it to Cameron and he agreed. So we drafted a document which, basically saying hey dns64 is while you deploy it for six, for ex-lap is quite the deploy. Yet we have also support for dns64 in happy eyeballs. We have also not sixty-four widely deploy it, especially in cellular networks.

J

There are million of costs using those mekinese and what happens is that horse validating dns act may fail the same command. I I did before it's true that most of the server networks, the the smartphones, are not validating, I think they have functions that can be call it by applications to validate, or that can happen in the future, but today is not used, but what happens when you are doing tethering and there are horse behinds that may be validating, so it's still a problem.

J

So the other thing, the other consideration is a big cost of the transition is on the back of the espys okay, because at the end the ISPs are the ones that need to deploy these transition features and need to solve the problems if the NSTIC is broken or whatever, and at the end, that means the users are paying somehow for it, because, of course, the the ISPs will carry the cost to the end-users.

J

So why not try to find a way for content or application providers to carry at least part of the cost? Okay, the thing is: if they have the technical of to do the intersect, they should have as well the technical ability to do ipv6, so that will solve the problem. Clearly, if we have ipv6 in every DNS SEC horse, we don't have dns64 breaking anymore that functionality right.

J

So the thing we are trying is to find a way to push the application or service or content providers to to deploy ipv6 if they are deploying the intersect. That's the first thing and then indirectly, to assume part of the transition cost as well and find a way to get them clear signals that this should be provided. They should really make an effort on this. That's that's the thing.

J

So the goals of the document is: let's make sure that the NSF infrastructure is ready which ABB six so dns64 is not any longer a problem, even just for one point: seven percent of the cases, one point: seven percent of the cases in a he'll desk of a nice piece is still a lot.

J

Obviously so so we need to try to sort out that make sure there is a plan for the rest of the DNS infrastructure to be as well ipv6 ready, okay, so one site is the NSA, but not only let's, let's try to figure out how to work that.

J

So what we want to men, which ipv6 ready, is that ipv6 is accessible, that there are quite a rare resource records that pm-2 is not broken and so on, so that that's that's easy, so we are trying to define a time line to make this happen and the time line is root until this, and we know that most of them are already done. Roots are done already, TLDs I think 99 per second of the CCT.

J

All these are done, but there are still some GT all these that are not done despite the I can contract man days. For that. So that's interesting. There is a contact that says you should do it be six, but it's not being enforced.

J

So we are asking them to be ready with JP, be six in six months, the same for DNS SEC infrastructure, and then they name servers in twelve months, another resource records in eighteen months and then hub, Ayana RIKEN, or what I'm doing at validation and forcing somehow suspension to those registers that are not doing that.

J

It's this an auto P I, don't know, but clearly there is a contract which I can. That is not big, follow it and yes, we are ITF. We are responsible of the numbers, so somehow we are indirectly responsible that this is happening or not right and there is clearly some kind of infrastructure or liaison or whatever, which icon that we should work together.

J

So maybe the document is not the last war on these clearly and maybe is not the only way to go for this, but we should do something and- and that's I think that's the last. Is life yeah? That's that's! That's the thing so throw tomatoes, so whatever I know Jen so.

B

Let me be clear on this: you're asking I can to essentially take a regulatory position. Well.

J

If you have something in a contract- and you are not enforcing it, why are you happy doing a gun front so.

Q

Jordi, its yep dan, you work I spent some time before when I was in more of an ipv6 advocacy role and I was very excited when that contract that you're, referring to it's the registry agreement. But the detail is that only applied to the new gTLDs. It did not apply to any of the country, code, TLDs, etc. So I think, and most of all of the new gTLDs are ipv6 because they had to be in in order to be launched. The I can process. So that was so.

Q

Regarding that the contract point it is affecting all the ones it can affect, so there's all the other domains, the CC heal these the other pieces that were not part of that in various ways. Although Warren may be able to correct me if he has no.

R

Okay, alright, looking at him, okay,.

J

I know I know in fact is not affecting CPLDs, but luckily cctlds there are only three or four that are not still doing so. That's the mean of of of the problems so yeah.

Q

Okay, anyway, I don't know that chasing that's gonna. Do too much. My my larger question, though, was or two one was. Have you brought this at all to the DNS op working group, I.

J

I think I forwarded a copy or somebody copied and I didn't copied, because I saw somebody already posted there. Okay, I didn't get any inputs I well.

Q

I would encourage you to do that. I will admit. I haven't been following as much here, but I have been over there and I think that would be useful to provide that input to. But the other part, when you ask about DNS SEC and saying that you know so, I agree with the goal right, yeah but I think from an implementation point of view, I'm not going to necessarily sign any quad-a records if I don't have them.

Q

If my web server is only accessible over v4, then, which is what the dns64 needs right to get to me so of.

J

Course we are not asking for that. If you don't have transit, which you should not have whatever records, that's clear, yeah, but.

Q

Then, how do you put I mean in what you're really saying in this is that everybody should get their websites and everything else to work over ipv6, which yes, I completely agree with that, but I don't know that necessarily we can I, don't know, I, don't see it necessarily being something we can necessarily create right there and.

C

Mark Andrews is in the queue yeah.

S

Yeah at the Tod level, I agree everything's pretty much right.

S

The problem is the the assumption you're making assumption here that if you can do dns sick, you can also do ipv6 and once you down a little beneath the tail days to the actual enterprise that isn't true, it is not true, to a large extent, to do DNA sick. All you have to do is to deploy a name server which supports it and register your keys in the pair exam.

S

That is something you can we've been able to do for 20 years. Nearly now it doesn't read. There's no gating on ISPs doing giving you delivering your ipv6 over your over access network and anything else like that.

S

So anything which actually get which actually slows down DNS SEC deployment by getting it on ipv6 being deployed, is actually a bad idea, the DNS SEC, which is why this craft this as a recommendation. You should do this yeah, it's it's all good motherhood stuff, but in practice it guess what happened so.

J

Mark so you are suggesting that we just stick to a recommendation and nothing else and don't work which I can I wanna do try to fix it, I, don't.

S

See, there's a room, I, don't think I don't see. There actually is a problem of that level, because the only one the ones which don't have ipv6 aren't contractually required to have ipv6 either because there's there's a set of T of these which have contracts and they do actually do ipv6.

S

Does that make sense. Yeah.

O

Paul Wilson here for maybe Nick very recent discussions with ICANN senior folks showed that though they are very interested in this. They are aware that there's a lack of compliance in the support that they're expecting for ipv6 functionality to be provided, but one of the things, for instance that they're after is that their registrar's should simply provide the interface that allows domain holders who have ipv6 to to register that it into the inter DNS. So I think.

L

They're they're looking.

O

At that functionality that the question of the functionality offered by the era they contracted parties I'm not sure, with the whether there's consensus on whether the contract is correct or not, but they are they're aware that they've got certain contractual requirements that aren't necessarily being them being met and they're, not maybe not monitoring as well as they could, and they were just they are definitely interested in.

O

J

It looks like if ionized or icon is in this direction. We should work with the liaison to try to define.

C

P

So if we think that the dimension of the maiden Claes that the problem is a Dennis operators, do not really understand the impact of having dinner check, enabled without the ability, v6 then I agree, we need to educate them. So probably so, I really like the first draft, which was just saying if you deploy it in a silk, you should think about the impact. You should be aware, as that some people might have issues accessing your record. So please consider an event ipv6, that's the right thing to do.

P

However, what your draft is currently said is that your suggestion to invent a magic wand which will get ipv6 deployed global in 18 months and I just do not believe it's feasible. So basically what your suggestion I could not see how it could be implemented. It's I just do not see implementation, details and I think you basically suggested something which is not feasible, so I do not think we should be enforcing this, because there are countries which do not have v6 at all. People who have sides there.

P

They just could not have be six in that time frame it just just totally unrealistic, so I suggest we stick with recommendations and explanations of the impact and that's it and, as it's been said, DNS ops people need to be aware of this because at last right, meet Nvidia working group had no idea about this document whatsoever.

P

Q

Second Dan, you work it just one comment the mark led onto it. I think you are off on the idea that somebody who has DNS expertise is also. If they have that technical expertise, then they could do ipv6 because to Mark's point you know, activating DNS SEC on a zone is really just a matter of maybe uncommenting a line in one of the config files or doing something like that and so boom. You do that and it's on and now you're signing all of your zones, depending upon which of the various different, authoritative service you're.

Q

Using so that's I mean a very basic thing that you're done versus trying to get ipv6, transit and ipv6 routing and everything else and firewalls and all that configured. So it's a different technical set, so I would not make that assumption in there too, to Paul's plan I think there are people within ICANN and in NSR, C and other folks who are out there working on ipv6 issues, who you would talk to I. Don't know that Ayana has any role in that type of thing with that, but I can would be the folks item.

Q

Yeah, thank you.

B

Balint as far as hi anna goes there a service function. They do what they're told so that thought thought their job.

B

So, okay, what I think I'm drawing out of this and tell me if I've got this right. Oh you're gonna need to change the draft to make that beer recommendation as opposed to the contractual thing we need input from DNS ah either you need to discuss it in DNS, op, review, yeah.

J

I think I think is trying to ask the Ennis ought to read the document and provide inputs.

J

Probably after that it will be clear that it should be just a recommendation, but I think we should still work with the liaison which I can to see if they have some suggestion about the document about way to go and if they can do something. Maybe I don't know. I am just thinking.

B

So are there any other things that I should be pulling out at this site? Those are the two points that I'm pulling out at them. Okay, so I have one other question. During the discussion a few months ago on Cameron's document, there were several people who said that they shot thought his document should go to BC P. So let me ask the working group. If those changes are made in this document, do you want to take it to bc p question for the group? um If that's a direction, you think it should go.

B

Would you please hum.

B

The one he's just been talking about.

T

B

um Okay, thank you. um So, okay.

B

So now moving along six.

J

One seven seven yeah.

B

And I'm amazed you're an author on this one as well. Yes,.

J

Okay, so what we are trying to do to address here is the perception of many ISPs read the 677 as something which is not very, very clear, so I decided to speak with the outers of that document and try to see they going to get involved in this version and I think we didn't get a response from Thomas, Martin and Jeff said: I am NOT interested at this stage and then leader over said. Yes, let's work on that, because she has the same perception.

J

Okay, so the thing here is that we move it from RFC three, one, seven, seven, two six one, seven seven, and then we somehow tried to fix the idea that, as last 48 is good for for everyone.

J

However, when you read the policies of different registries, some of them suggest to still use his last 48. Some others suggest his last 56. In any case, it's clear in all of them that it's an isp decision and we agree with that.

J

But the people is still doing some strange things and when we ask them people I mean I speak. When we ask them, they don't have a clear understanding from from our point of view of what this document is saying, the actual 677.

J

So let's make make sure that we fix this document, especially to say a site needs to help many subnets, not just one and a single as last 64 is never recommended. This is somehow already in the document, but we want to make it more clear. Okay, I was working for two years and is still ongoing in a survey the last time, I'd look at the figures. Probably about six months ago, I had almost 1600 responses from ISPs from all the wall.

J

23% of the ISPs, mainly from more advanced countries in terms of ipv6 deployment, are using as last 48 for residential customers.

J

35% are using as last 56, and- and this is the big problem there is 33 percent that are using a single, is last 64 for rental customers. Okay, and when we speak with those they are somehow pointing to energy 6 177. So that's that's the reason we believe it's is broken. You want to say something now: Barbara, okay, so what we are trying to do in this document is to update the recommendations.

J

Stop them are exactly the same as we had today in 677. The first one is a single is last 128 is extremely discouraged it there are not in ipv6 hard-coded boundaries we use c IDR.

J

One-Size-Fit-All is not necessary or appropriate, but we still need to ensure that insights get a sufficiently big number of subnets. A single is last 64 is not a normal choice. There may be cases, of course, but is not a normal choice. Neither should be a small number of subnets and we don't go to define what is a small.

J

Ok, we don't want to enter into that discussion because that will be endless inside should always be able to take a reasonable number of his last 60 force for the rectal and planet usage and over time range is specific in many years, probably decades. Ok, so we are not talking, get the use of something for the next four years, get them something for the next 20 years. Ok,.

J

There was we are following more or less the existing structure for for the for the 677 that we have today. Actually, our version is shorter because we deleted some some of the sections, but there was one section that speak about.

J

Why is last 48 and what we are saying here is per address cost, considering the charges from the resistors is not a problem, so that should not be a stop a showstopper for an ISP to to to allocate more addresses or more prefixes ComNet control protocol needs super segment to downstream routers, so maybe, as last 56 may be too short in those cases, use of ul is internally not matching the ISP prefixes, so they you last 48.

J

If you want to match that which the preface that you get from the upstreams is not going to work. If multiple links are present, DNS is simple: with same traffic size from each link. Instead of having different is business. Different traffic sizes business may need more than a single as last 48 and the actual addressing policies from the resistors already allow it.

J

Even in some cases, they still need to go for a justification, but this is something that Google need to fix at the policy level and I am actually considering submitting policy proposals in all the resistors to fix that single is last 64 per host interface is something that was not considered when this draft was was done.

J

This document was done because it didn't existed, so we need to consider it now and then, as last 48 is not graceful in many situations, because one of the reasons from moving from three one, seven, seven two six one seven seven was people saying, is graceful and then I did those numbers which spreadsheet to show that is not wasteful.

J

If we have as last three that contains that number of slash 48, if we are really really really bad, deploying ipv6 and we have a fifty percent utilization, we have only the half, of course, and then, if we suppose we are going to have 32 billion population and that they average expectation for every human is hundred years, and, let's suppose that when everyone dies, we don't recover this last four days that get to them. We can give as last 40 is for the next forty one thousand a hundred thousand years.

J

If we go for four is less 48, we have only twelve thousand eight hundred years and we still have eight times that space. So if we use all the dressing space, it means that we will have at least for the next hundred thousand years as last 48. Okay, you to say something now: yeah.

G

Julie, that's a curiously naive modeling of human behavior and addresses are actually not used by humans, they're used by machines so well I, don't I it's hard to even criticize the model on which the assumptions in this slide are built on, because it's not well described but I think it's I think it I think we can be reasonably certain that that assumptions that you have there are completely meaningless. We can use all this address space in two three four decades, maybe without too much trouble.

G

So fifty thousand years is maybe three four five orders of magnitude off.

C

Okay, Ron Ron Bonica speaking as an individual contributor I think this slide may have been more for humor than for actual modeling, even if he's off by four orders of magnitude, we're still.

J

Okay, he's still, okay, that's the thing. I mean I am NOT trying to be accurate because, of course, he's not just human. So.

C

James, you expected us to chuckle. Obviously,.

U

Chief Houston, not chuckling part of the reason why we had a problem with the 3177 or whatever it was, was that in looking at the ratios, we were using in deployment and 50% utilization is a laughable joke. The whole idea of v6 was not to place pressure on operators to achieve address utilization densities, which were expensive.

U

The whole idea was to be enough space that it really didn't matter and the combination of using enough dress space that it really doesn't matter and projections of device density meant that assigning a / 48 to everything would give us less than a decade. If you happen to read the stuff, what I object to about this kind of slide is joke mathematics, it just doesn't cut it and the case that they're trying to make that slash, 48, SAR, fine implicitly behind this, is completely and utterly false. In my mind, I reject that as being irresponsible.

U

If what we're trying to do is to utilize the larger address space in v6, not to repeat the phenomenal pressures we placed on this industry to strangle v4 beyond its reasonable lifetime, then what you're doing here is, oddly enough repeating that same mistake- and the least we can do- is learn from this. So no it's not funny. It's actually misleading and wrong. I'm! Sorry, it just doesn't cut it. For me,.

L

Go ahead, Christian, Itamar, Jody, I kind of agree with what Jeff said and one thing you're missing there is that the pressure is not linked to the ratio that you are using. It's actually look a bit meek and we explained that in RFC 4180 for and if you do, that, you should actually go from there and if you go into the logarithmic effect, then it's very much closer to just position than yours.

K

Okay, keep going.

J

So the summary of our document is that exact, perfect choice. It's still an operation issue and we have a reference to a very recent document from Wright which has been quoted by operators from all the regions which is riped 690.

J

We strongly discourage using a single as last 48. We strongly suggest considering as last 48.

J

Alternatively, we reserve as last 48 and assigned the first as last 56 that will avoid remembering the remaining is last 48 can be a sign if you need it later or use it for other users if it is not needed, encourage alignment of cellular networks, because that's that's another thing we have in silver networks.

J

We are providing just as last 64 and we don't use the HCP and so on, and- and the thing here is that the the reason for that is because it's an alternative to broadband networks, right cellular networks and more and more alternative to to broadband, and in some cases there may be users that only have cellular connectivity for their broadband connectivity, and today they got only a single is less 64. So we we want to make sure that that's also fixed and that's it basically so Barbara yeah.

I

V

Disagree Geordi, first of all, I guess on various levels. You mentioned the mobile networks, which are handing out the SAS 64 effectively because there is no DHCP I, a PD in those networks and right now, 64 is the best they can do with the mechanisms they're using. Yes, it would be lovely if they handed out more but I think that putting out some strongly worded RFC that says you know we really discourage slash, 64 and sending it to them, and it's like tilting, it will windmills.

V

You know there are also operators who have our six Rd deployments, we're providing a slash, 60 and telling us slash 56 by gully and slash 48, again, you're, tilting at windmills and it's kind of insulting I mean we've got ipv6.

V

You know if you start putting more and more barriers like this in front of ipv6 deployment, then you're actually going to, in my opinion, decrease ipv6 deployments that still need to happen in so much of the world and I. Don't think you have made a case for why this extent of address space is really needed.

N

Lorenzo clitty, I think I think this is a tussle and and and the reason is that and the reason I say that is that I disagree with everything you said: Barbara well, pretty much. Everything I agree that saying it's like I agree that saying something super wordid is not gonna help that much. But I think I think we have to say something here. I think we have to say here's what you can't do when there's when you just use a 64 and it's I think we have.

N

We have guidance on this in in terms of our ir policies, but we also have to have guidance to isp, saying look. Our protocols are designed for this, and that is a statement that the ITF is qualified to make. It has to make right. I think we wrote a bunch of stuff I, don't know. Was it 10 15 years ago these days and we wrote a bunch of stuff about address sizing, and you know that was before ipv6 was deployed, and now we have operational experience and I think.

N

Yes, there are operational reasons to assign a 60 to assign a 64, but there are not good things to follow in the future right when those operational reasons disappear, like the fact that you can only do a 60, because if you're 6 Rd pools are given size, we should move towards 56. If you have a native network, there is no reason why you can't do 56, and if you don't know that as an isp, you should now. If their operational reasons, sure I mean reality takes precedence over wish lists.

N

But we have to say something here, because otherwise people might just choose whatever everyone else is doing and then we'll just fall into a minimum common denominator trap, and we shouldn't do that. Thank you.

W

Eric lean I guess I wanted to ask: is it? Is it more appropriate to have our er documents in this context? Is this a night? Does this need to be an IETF level document? Do we need to have a re.

J

Are in my opinion, and that's why we working on this, we need to have documents in in in in different directions. Do.

W

The are ers needed, IETF document to refer to yes,.

J

It's good sometimes.

A

C

I'd like to let mark in to the queue.

S

Yeah two points: a sticks, ID there's nothing stopping any 6id operator from deploying slash 48 to every one of their users. It's only when you start shoving the whole / 32 from ipv4 into the address that you actually become become size, limited in the number of prefixes, and what we really need to do is start trying to.

S

Describe how to not waste addresses be that the instructions to enterprises on how to actually allocate addresses. So if your enterprise and you actually just assign a slash 64 on demand, yep, you have 65,000 slash, 60 forced to hand out you don't need to have internal structure. When you heard her an enterprise, it might be nice that handing out the dresses doesn't require doesn't require internal structure.

S

It's that sort of thing that ends up wasting addresses.

S

We have routers, they know how to route things, giving guidance the end to the end sites on how to actually deploy ipv6 in such a manner that you do not waste addresses, stop encoding things into addresses, which shouldn't be there.

J

U

Jeff Houston again look either we're all commonly amnesiac and we just simply forget everything, or we endlessly repeat these conversations, so we can get more and more expert at reciting our positions. Neither of these correspond to progress. There is nothing in 61 77 that said user, slash 60 for nothing. It actually says the opposite.

U

As you might recall, what it did say, which is what you seem to be contradicting here, was that one size fits all is wrong and the whole idea of classful, addressing as we learned in v4, was actually a hideous mistake and deployments, and operators have enough nouse to figure out what they need to do and trying to do. One size fits all create such gross. An extraordinary wastefulness of address space that even the 128 s-- of these some bits of v6 get wasted almost immediately.

U

We can hear through this space in a year if we really want to, because we're endlessly inventive I do not see anything in this draft. That justifies why we should be doing abyss on 61 77. To me, this seems like a complete waste of time. What we said, then, is true. Now there is no one-size-fits-all go pick. What you need to do by the way a slash 64 to insights is kind of difficult for those insights.

U

You really shouldn't go there or, if you do understand very clearly what you're doing, because it's not the best idea beyond that. Go figure out what your customers need and do the right thing by them, not as you're saying strongly suggest going back to the exact same problem that prompted 61 77 to come up. So you know I'll keep on saying this and you'll keep on doing that throughout the next five years and we'll all feel good about it.

U

Will we or can we get over this stuff and actually move on to areas that are productive because, quite frankly, cycling around these conversations is just a waste of everyone's time. Thank.

J

N

Learn zouk lady I do think we need something that discourages a single / 64, because we have things like HomeNet. That say that you shouldn't do that and I think we I think I think it's worth writing a document that says look here's what we learned and here's what we think this should look like in the future. I, don't you know, maybe 61 77 says exactly what we need to say for what it's worth. I mean Jeff. Is this just because you don't you don't like 48?

N

If that said 56 well, you would you sort of be happier because that's actually the de facto size in our a our documents.

J

Lorenzo summer IRS uses less 56, some others keep using his last 48. So it's not the standard. Okay. Thank.

U

You Mike I'll, try and paraphrase my understanding of our IR policy and I. Don't want to be authoritative about it, but the our IRS heard very strongly in their policy fora that one size didn't fit all and what they allowed as far as I can see, is v6 allocations based on what the operator said they were doing and it's not a / 56 or a / 48 or anything else. There is a charging structure in a lot of the our IRS we're forced some of them.

U

More space means you pay more money, but that's not all, and quite frankly, it's none of the ITX business to intrude inside that area, but no one inside the our IRS as far as I understand from policies perspective is saying it's 56, 57, 58 or whatever. That's not the business anymore. We some.

J

Of them kappa recommendations.

U

This is not an RI armaiti. The second thing is sixty one. Seventy seven says very clearly: don't go down the / 64 path and I really don't understand. Why we're having a debate about that because, as I said, you couldn't make it much clearer if you actually read the taste, so I don't see where the problem is on that side. So you see this is.

N

Basically, already stated in 61 77 people.

J

Is not reading that way.

X

So just pushing back on the last one and so going back to 33 14 from 2000 like we had this discussion and we really recommended 3gpp to go its last 64 and it was like a big big battle to get it pushed down there. People say: oh, that's like really wasteful and everything I. Just don't want this to be the open again, at least for the cellular.

X

I know like Lorenzo's gonna come back here, probably, but everything that needs to be said has been said in 79, 34, okay, it says like what can you do it this last 64? What you cannot do so I think that work, at least for the cellular side is done like I. Don't want, like anything, specific saying, put in a bigger prefix for a cellular network, because this is like really entrenched and we're really happy that this happened, that everybody got us last 64.

X

So you can do like creative things, like you know, like four six 4x lad or you can do things like you know, 64 share and things like that that that came out, because we did this at 64, so I just don't want to miss to be revisited anytime soon.

Y

From the jabber room, Brian Capron, tur, says RAC 61 77 says, and this document still recommends giving home signs significally more than a singer, slash 64, but does not recommend that a vm site be given a slash 48 either.

K

Hi Bob Hinton two points from the discussion, so certainly, if we are not prudent, we will use up this address space very quickly. It's we know how to do that. So we do need to be. You know careful how what allocation policies are, and the other thing that I'd like to add is that the intent behind this was not to make the ISPs better. It was to give the N sites enough address space, so they could do whatever they needed to do so.

K

There wouldn't be address scarcity like we have with before and that's you know, thinking, or at least my thinking was that the ISPs have resources and can manage it their space and they conduce. They can deal with complexity at that level, but the insides can't and if we make it hard for the insights to get enough presses or having to renumber frequently, then we'll end up with that again exactly.

N

Lorenza Khalil I, you know, I think what if we said, simply assigning a single size, 64 per site is not recommended, I mean I, think pretty much. Everyone agrees with that right and that's clearly not being done everywhere and the reasons are varied, but I think if we I think even ice. Bees would agree with that aspirationally. They would like to assign that and I think it's important to state that in a very simple way. As for cellular networks, I mean Suresh.

N

The that's actually a great example of how what we said made a difference, and it's it's a shining example I. Remember a major one of the earliest adopters of ipv6 and the person at that operator who was pushing my pv6 was I'm, not gonna name. Any names here was convinced that 64 per to the device was super, wasteful and was really stupid, and that operator discovered after deployment that actually this thing that they had assigned a 64, because the stupid ITF had forced me to do that. I was like oh cool.

N

Now, I can do 4, 6, 4, X, lab, and so so I think I think I. Think there is value here and I to be honest. I do see. I do see the point that we should say. If an LTE network is a an alternative to to home networking, then it should assign a 56 or so or whatever right. That's.

O

The thing that's valuable.

N

And- and we shouldn't say like: oh don't assign is 64 right, but and- and you know it's to the earlier point- that date- that mobile networks don't support HPV 6. Well, it's written in the standards right. It's not like it's not there. In theory, you know, maybe the gear doesn't support it, but it's there since release 10, so I mean I. Think that that that's a good statement to make you know if you want to provide an alternative to to home routing to to home.

N

If you're doing 5g, because like of you're like one millisecond or air interface time woohoo right, then you should assign a 56 if it's an alternative to home. That ok I think that's pretty reasonable. Thank.

C

You kevin is a individual contributor I, like one of the things that Lorenzo said a lot that we should have a recommendation that says slash, 64 or shorter is a really bad idea. There's also- and yes, it may already be in the existing draft yeah. Then there's a need to specify an upper limit and.

C

An area where we give operators free rein, anything between the upper and lower limit is just fine. Now the question is: what's that upper limit? The best thing we have to judge the upper limit. Your analysis, which was clearly humorous, but not serious and I've, also heard that if we use slash 48, we can run out in ten years.

C

That may be true, but supporting facts would be good, so maybe it would be a good idea for, like the two of you to sit in a room together, oh and do a serious analysis of what number is too big.

X

Yeah, thank you so Brian I don't know if you're ahead of me or not but yield to you if you're before me. Oh I'm, sorry, yes, Brian.

C

Brian go ahead.

C

Brian II there, okay, so.

X

Just like going back to what Lorenzo said, so there is some limitations in in cellular networks. Okay, so we've done quite a bit of study on this on a fixed network. If somebody gets this last 64 and they decide they need more at this pace, they asked for more address space and they can get a 48 or as 50 like 56 or 60, whatever they want right. But the way the cellular networks are architected, they get only one prefix. It can be a what Evelyn. So if ITF decides like hey, everybody should get a slash.

X

30 do like fine right, but but once the session is established like putting in a second prefix, it's very, very difficult. So bunch of us worked on this thing together. I think, like Ola worked on it with me and youngy like few P, we worked on it, so we figured out, like you know how to delegate a prefix with the hole in it so that 6603 that came out from like you know, how do you take a prefix, take a whole lot of it.

X

So all I get is 64 and then allocate the other prefix on top of it, so which is all separate from saying like what length do we want, and but what I'm saying is like this last 64 discussion back in like 2002, was like very painful. Okay, already people thought it was very wasteful back at the time.

X

So, whatever number we come up with right now, it's gonna be equally painful to have that discussion, so I'm really happy that we have the 64 there and we can try to push like further if needed, but I think 64 works well for mobile networks like for mobiles and as like Lorenzo said. If it becomes like more like a site, that's behind a mobile network, then maybe we can come up with a slightly more targeted recommendation for other things in there. But I don't want this to be like a chain.

X

Drake idea, like tells 3gpp that every Mobile gets a slash shorter than 64 okay. So thanks.

U

Geoff Huston I'm just going to remind the IATA from this working group where we are because 61 77 is a BCP now underlying this is where does address allocation policy happen in the internet and a long time ago, after a lot of fights- and some of you might remember- PR, we kind of said to the our IRS- will give you architectural guidance but URI hours of the address policy. Fighting room go there and hash it out. The ITF can recommend that it can't enforce so 61 77 says very clearly.

U

The IETF recommends that any policy on v6 address assignment policy to end sites takes into consideration the following points, which is an appropriate language for this working group. You can't say Oh URI eyes have to do this or that it's beyond your scope, your arms aren't long enough. You can't reach that far point one. It should be easy for an insight to attain address space, to number multiple subnets ie, a block large single / 64, and to support reasonable growth projections over long-term periods, either a decade or more.

U

If that doesn't say, don't use, 64 I, don't know what does. Secondly, the before yeah typically I'm. That's why I'm helping by reading it out the default assignment size should take into consideration the likelihood insights we'll have need for multiple subnets. So my point is: all of this is stated already so I really don't understand exactly why we're circling around this again and again, and the real issue is the architectural guidance might come from here, but the feet on the ground is actually inside a different room, a.

Y

Bruin carpenter gain, even if I don't look like him. It really says that RAC 61 77 doesn't say that 60 says first /et 42 small / 48, maybe too much so poor. So apart from making people read 6157 again, what's you.

N

I think we we need to bear in mind that 160 177 was written v6 deployment at the Internet's to the 0.2% okay. Now it's two orders of magnitude above that and I think we can. We can it's kind of like amazing to me that 61 77 has a BCP cuz, there's, basically no deployment right, so it wasn't a current practice.

N

It was a future practice to CNBC piece you've been like BFP or something so and to your point, Jeff I think that text is so easily that people can read whatever they want into it and I. Think while I would agree with you that it says, don't do slash, 64 I think there's benefit to saying: don't do slash 64, because if that's, if that's what everyone agrees, it says, then let's write it in plain English right. If we already agree on it, you don't do 64.

N

Unless you have some strong operational reason, then you know what's the problem with that, let's just write it in English, though: let's not write it in sort of weasel words, a stronger.

J

Warning is needed not.

N

A stronger wording, just a clearer wording. Do you if.

J

You were that strongly like yep.

N

21 to 19 well I think it I think it's. You should write yeah if you have a legitimate operation reason right yeah. So if we said should not use a 64 right, how many people disagree with that?

N

I didn't think this room would I, don't think the IRS would either because the IRI has already say: don't do this, so let's just write it and in plain English and say: look if we want to I I think, from my perspective, having a clear document as a win and I think if we want to say look: here's after, like whatever between 0.3 percent and 25 percent of v6 deployment, here's what we learned and here's what we want to recommend. Let's do that thanks.

P

John linka I've been listening to this. That looks like we just basically discussions that the few section in the original RFC is not clear enough. Should it just be a very short document, saying: let's update this text with zebb text and that section and we are done making it more clear and to wrong point about providing upper limit. I do not think it's a problem.

P

We have now right because I think practically most of the real problem is that ISP is assigned just slash, 64 or even slash, 128 I do not think we have problem with two blocks assigned being too large, so we probably do not. I am Not sure we need to concentrate on discussion. Should it be slash, 48 or something else. We need to make sure we're not assigning too little because it hurts. If you assign too much well, you burn out your address space.

P

You have to go to area our back and ask from address space and pay more potentially. Well, it's your problem, so my opinion. It's not real and.

C

At this point, we have to draw this conversation to a close and bring it to a spirited discussion on the mailing list. Yes,.

J

Please I will suggest the people that that happen not read. The document make a deal between the original six 177 and this one, because the difference are not that much so I agree with Jen that it may be a shorter document. Yes, this document is shorter than the original one, so we actually remove it. Parts of the original document.

B

So, okay, let's take this to the list now, so we have one document left today and find in the story: you've been busy. I have six more.

J

Okay, so this this document I think, actually, you suggested doing a comparison of the transition mechanism. So GABA, which is the main author of the document, said yes, I, take it and ask it for volunteers, so few of us started contributing I know we have short time so so I I did a very, very small presentation, because the main goal of this presentation is to to get input from the working group. Okay.

J

So we need a lot of work here and we don't expect this document to be an easy one or something that we are going to do in a in a short time. So basically, what we're trying to do with this document is. There are five basic transition mechanism that we call like ipv4 as a service which are four six four X Latvia's light like way for over six months and mati.

J

There are a few others like Lee's theory on ipv6, and so on that we decided not to consider, because there is not that much deployment as the previous ones, so we prefer to concentrate on de what we believe are the five mine ones. If somebody disagreed, please state hey, there are that many number of deployments which other documents, sorry which other mechanism- and maybe we will consider that.

J

So the thing is if we try to make a comparison between all of them to make easier for an ISP to decide- and we already know from the beginning that this this is not really an easy task and at the end it will depend a lot on every specific Network case. So we have different sections of the document again.

J

The document is still work in progress and we'll retire of additional work, but we have one high-level architecture where we discuss each of the transition, mechanics their trucks in the SP network and how they are sharing that in four addresses for for doing this mechanism.

J

Okay, so summary of the document, we have the toilet analysis of their detector architectural differences between the different, the five different IP for a service mekinese based comparison of all of them, trade-offs among the efficiency of poor numbers and stateless operation, support for servers, operation, support and implementations, including operating systems, cellular and broadband and implementation Co sites.

J

We have also typical deployment and traffic volume. There are some figures that that Cameron from t-mobile provided to the mailing list. Oh we compared it. Those stickers which other similar makers- and it looks like like most of them, are, coincidentally in that in that sharing, so we are basically describing the deployment possibilities, including the server which, for six Forex lat, the load sharing performance comparison. This is something that we want to do so this is not still done, but the idea is Gabbar has some students that will be able to do this performance comparison.

J

We still need to define exactly how we are going to do that, because it's not an easy task, and that will be part of the document and, of course, we'll have a security considerations, and, and that's it, they thing here is asked to the working group to contribute ask to the working group. What other aspects do you believe are interesting to to be considered by the document?

J

What do you think will be useful, Barbara, yeah.

V

So something I think would be useful. Is a number of these technologies actually have various options as to how they can be set up? You know, maybe you have blocks of ipv4 addresses associated with it, maybe you're using that you know, there's all these various things, and so it would be useful to understand what are the most common configurations that are in use.

Z

In thumb, yeah, first of all, thanks for grasping the nettle and try a handle on this stuff, because it's.

L

Z

Expensive task- and it probably should have been done some time ago- I gotta, look through it and I've got a raft of comments and the current version of there, which I'll post the list later on, but the main things I had some there's been a spreadsheet. That's been doing the realms over the last few months and I think Lee, Howard and well, based on your work.

Z

That does some kind of comparison between these things based on kind of yes/no is, and you know, are very easy to look up and something is the plan to kind of incorporate this stuff, and you know find some ASCII way of rendering that that thing, sorry is. The plan. Is the plan to incorporate that comparison table?

Z

So here's an easy and yeah yeah, okay, good the performance, testing, I I mean we've talked about this one already, but I I've been kind of wracking, my brains about this as to whether it can anything meaningful come out of this. That isn't just going to say this implementation is faster than that implementation. You've got physical versus virtuals, you've got God knows how many different variables on here. To be honest,.

J

We still don't know, we are still thinking about how to do that and how to put that in a document, because we know that there are person cons to every possible option. So yeah I am.

Z

J

Sure about how we be doing.

Z

My gut feel here is that, unless you're, comparing different implementations, a single technology, you know you can't come out with anything meaningful right and there's a you know the risk of well very time consuming about inconclusive waste of time there well.

J

The advantage is that we have the students that are happy to do that so yeah, but I.

Z

Mean do they have.

J

Z

All of the different hardware and software implementations- that's.

J

Another month of ours.

Z

Right unless they're very well resourced I doubt it.

J

Yeah, thank you.

B

Okay, so now at this point we have only a couple of minutes left until the top of the hour. Are there any further comments that people want to make to jority on this drought?.

B

Seeing none, okay, the time is now 1054, I. Think by the time we do anything, it's gonna be 11 and 11. We're done so I'm. Gonna adjourn at this point. We're gonna come to thank.

L