Internet Engineering Task Force 108, 28 Jul 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF108 6MAN 20200728 1100

Description

6MAN session at IETF108
2020/07/28 1100

A

A

Well, shall we get started.

A

And ollie, I can't hear.

A

A

Oh wait: can you talk?

A

A

A

Barbara, can you still hear me.

B

Again- and I see oolay tron's screen seems to be coming up.

C

Okay, you can't hear me, though you can.

D

C

You cannot okay, excellent, so bob take it away.

A

I'm not sure I'm awake enough, but.

A

Welcome to sixth man working group, itf 108., um we have um an hour and a half, or so I think um why don't we next slide.

A

um We're using obviously we're all on meat echo. Now we will present the slides.

A

So you don't need to share anything if you wish to speak, enter the the audio queue um there is also a way of just speaking directly. um I think that's probably not the best way to do it. We we will manage the queue if you request it um and when you speak from it please state your name.

A

The blue sheets are automatic, there's nothing to sign and the notes are on. I don't know how you say that code codemed something um and there is a participant guide for the session and meet echo documentation next slide, and here is no well. So please note it well next slide um the usual information jabber room.

A

Well, you should have found the link already um barbara stark is taking minutes. Thank her again.

A

Oh good and we, uh I think we still need a jabra scrub or we need a jabra scrub.

C

It's it's I mean both of us see the queue and- and I think everyone is on btco, so I'm not sure if we really need one. But if, if someone want to step up, that would be great.

A

A

Yeah I mean I have a jabber window opened up on my other display.

A

um Okay, this is the agenda for today um and any um any agenda bashing.

A

Okay, I'm not seeing any requests um next slide, and this is we have a 50-minute session on friday, and so we um yeah go back one slide.

A

So we organized this with the working group drafts today, one active internet drafts and then and then a new individual draft. Today, hopefully we'll have time and then the next slide, and then one working group draft on friday. The path mtu, a report on the path mtu option and then for new internet drafts. Okay,.

E

A

Slide: okay: ollie! Do you want to do document status.

C

Yes, um so since the last ietf uh or the last entry meeting, we have published one rfc, it's the uh the uh ra preference 64 option.

C

We have one document in the editor key, which is the icmp limits one, and we have finally submitted the temporary address extensions to the isg and currently nothing in last call.

C

In working group last call, we have two documents: it's the oem for segment routine and the gratuitous neighbor discovery, one, the gratuitous one, we'll talk about on the agenda. The oim one, I believe, is now passed all the outstanding comments and is ready to advance.

C

um We have two working group documents. We have the pathmq hope I hope option that's on friday and then the alternate marking method, which we'll talk about later um so we had two somewhat outdrawn and contentious last calls it's the one on the cr8 option in the compact routing header.

C

um So we sent out the statement here which which basically says that we reached an impasse and we're now awaiting the outcome of the spring design team um that was discussed. If you were in the spring working group yesterday, it was discussed briefly, um so there are still some concerns from our side. I think on the on the expedience and timeline for that design team and I think they initially planned to report.

C

You know somewhere around 909 or 410.

C

So we had to follow that that closely uh and then there is the the uh improving well hang on so andrew. Yes, you can have a comment on that. Let me just click on.

F

Button um yeah, so it's andrew here from liquid. um I do have a question about that timeline, because I've obviously been following that now.

F

The current status of that, as you mentioned in spring, is actually at best ietf 110.

F

Now that leaves me rather concerned because you know that's that's quite a way away and this document has been around for a while. So my question to this working group is: are we going to sit and have to wait for something that's going to come only in ief 110, considering that crh is likely to go full production deployment in code in routers within the next month or two I mean it's, it's deployed and it's functional and to have to sit around and wait.

F

You know all that's going to result in is more development that is happening on something outside of the auspices of the ietf and that can lead to all sorts of problems later on. So what are we going to do if we cannot bring that time frame forward.

A

So I I think my answer to that is um we're not quite sure I think I was speaking for myself. I think I was um expecting something sooner. I think they did report yesterday that there would be some sort of first report in about a month or something, and so I'm looking to see what that says, but I I agree, I thought that the timeline that was presented yesterday in spring was um excessively long to get this issue resolved. So we we will follow this.

A

We are discussing this with our area directors and you know we. We understand your concern and so yeah I think ron is look if ron is in the queue for.

C

I think ron you're trying to share a screen. I think.

G

I don't think I'm sharing a screen. Am I.

C

No you're not yet I think you possibly.

G

Tried to yeah, no, I didn't do we have a red line date, um a date at which we'll say we can't wait any longer, I'm not interested in knowing exactly exactly what the date is, but you have one in your head.

A

So the simple answer at the moment we do not- I mean this. This was news to us yesterday we were expecting something sooner so we'll we'll have to follow it and, let's let the working group know.

G

Can I put you on the hook to like publish a date at buy a date.

C

uh I think it's very unlikely that we will get a date, but I think we should keep uh following up on this and I'm sure ron. You will keep us honest on that as well.

G

Yeah the reason I keep keep pinging you about that is no date and no answer is the same. As you know,.

A

Understood: okay,.

C

So, thank you, um okay and then uh so that was the crh documents. I think that will be an ongoing action item for us all for for quite a while. um Then we have adopted the robustness for slack uh document uh we or we kind of adopted a problem, but not the solution. So so that's, uh but that's also on the agenda. So we'll talk more about that. That later any other comments on the document status before we move to the first presenter.

C

Fernando has one: let me.

C

C

We can't hear you if you're talking.

C

We still can't hear you.

A

You know you wanna advance, put this slide up.

C

It might be, uh I don't know if you had a comment, but yes, let's it's, it's not fernando's.

C

But it's interesting, I think, ron grabbed my screen sharing. Let me see if I can start that again we are going to have some hiccups with this tool, uh so just bear with us.

C

Okay, um for now we can take.

E

C

Your comment later, if, uh if you get your audio fixed in the meantime, let's start with uh the alternate marking method. uh Gusefi are you here.

C

Okay, you should have both video and audio. I.

A

Think we can see you.

H

But you can, even you cannot hear me.

C

And we can hear you.

A

We can hear you.

A

Go ahead: okay, good.

H

Yeah, this is the update about the application of the alternate marking meter to ipv6. So next slide, please yeah. Just to give a recap about the methodology. The reference document are bought rfc, we can say, because we have rxc8321 and the multi-pointer mark graph, that is in the rfc enter queue.

H

In a few words, uh the methods consist of page by batching packets, based on time interval and by using one or two bits for packet process and delay measurement. Next.

H

Yeah regarding the ipv6 application, just recap about the discussion we had in six months during the last month. The preferred choice in the end was the use of option adder bottle by open or destination the source. Node is the only responsible that writes the option either to mark. Alternatively, the blue, while in case of of biop, the intermediate nodes may be configured to read this option or not, and the measurement can be done only for the nodes that are configured to read that option for destination option editor.

H

The option is not processed by any any node along the path until the packet reach the destination notes. Next,.

H

So, just a summary of the change that we made during and after the working of adoption code, so the draft was adopted some months ago and uh yeah. We got some comment from tom and eric that helped a lot to improve document. In particular, the comments from tom were very useful to build a new section on the uniqueness of blow monitor id, and the comment from eric helped to improve the security section after the feedback from wrong that we got during the last week.

H

We also plan to work on a new revision in which we will include the new.

E

Section on timing aspect and.

H

We're going to describe how the alternate marking is resilient to reordering that is already described in rfc8321, but it's important also to point out here.

H

Next yeah, the draft introduced the alternate mark option.

H

We have the usual tlb format, which the first three bits are all zero, because you have to skip if don't recognize and data do not change in root. While the in the red box, we have the important bit important fields for the ultimate marking operation, in particular the loss and delay flag and the flow monitoring identification.

H

H

Yeah, the flow monitoring identification field is required for some important reason. The first one it helps to reduce the per node configuration, because you can imagine that that if you have a lot of flows, you are going to configure a lot of access control list to select the monitoring flow. So the flow monitor identification is I'll, also allow a flexible granularity for flow definition.

H

It also simplified kind of simplifies the counter's handling and also in case of tunneling. It is the deep packet inspection so having the flow. Monitor. Id also helps in this direction, and it is also helpful for the collectors and controller for the data, export and correlation.

H

H

Yeah, this is the first section that we introduced after the comment from tom to allow the disambig. This is a migration of flow monitor already in case of collision. There are two possibilities. The first one is to use a centralized controller.

H

Is it is responsible to set the flow, monitor id and instruct nodes properly to avoid this collision, because, of course the controller has the view of the network and how the flow monitoring identification are distributed in case the flow monitor identification is randomly generated by the source node uh the situation changes because there is a probability of collision.

H

For example, if you have 20 bit, there is the 50 chance of collision for just 1206 flows. If we use the so so-called birthday uh probability problem, so for more entry for more entropy, we can either combine the flow id with other fields like addresses or label. Just in case in a controlled domain, we can ensure that the fp address and flow label can be considered stable or the flow monitor. Id sides could be increased by use, for example, the reserved bits in our data fields.

H

Next yeah, this is just to recap: the mark option alternatives the destination option, no bioport the destination option, plus any routing header. In this case it depends if we want to monitor only end-to-end, only of bio or if we want to monitor every destination node in the root list. It is worth mentioning that, in case of a biops, we are all aware that the object option is not well supported, but anyway it's important to say that for this methodology uh there is no strong requirement.

H

uh An intermediate nodes should in your this hobby option, but this does not uh does not uh have come strong consequence on the application of the methodology, because the performance measurement does not account for all links and nodes. But this is not so important. So just we can skip the nodes that are not configured to read the apply up option.

H

H

Yeah, this is the improvement of the section about the security we classify the security concerns about the harm caused by the measurement. In this case, of course, an alternate marking implies some modification on the option header, but this must be performed in a way that doesn't alter the quality of service. Of course, this is easy to achieve, since we are just changing two bits and only for the source node. So there is no change in route along the path regarding the harm to the measurement.

H

This is more important, since the alternate marking measurement could be harmed by routers or attacker that can altering the marking of the packet or injecting artificial traffic, and so on anyway, we can say that, in the context of a controlled control domain, the network nodes are locally administered and this type of attack can in some way avoid it. On the other end, an attacker cannot gain information with just one single monitoring point, but he needs to use multiple monitoring points to apply the methodology and to gain real information about the performance. So the.

E

H

Implies that there is no information on on local nodes, but on multiple nodes in a synchronous way and regarding the privacy concerns we can see that are limited, because the method only relies on information in the option editor without any use of user data.

H

H

Yeah this is the last slide about next steps, so in particular yeah. We found an agreed way in six months to apply these methodologies.

H

The next step may be the yana ipv6 parameters. In particular, we are looking for the temporary assignment to test the implementation and, of course, the questions and comments are always welcome. Thanks.

C

Thank you very much, so any comments, igor you're first go ahead.

I

uh So, first of all, I think it's definitely very important uh to have loss information and we've discussed it in, like uh I, I presented actually multiple times in tspwg. How important is this? So it's great that there is some more thinking in six man. um I am somewhat concerned that well, I'm actually more than somewhat concerned um that the thinking right now is purely about controlled domains.

I

So that's a very limited um area and the more it's very important to have lost information, especially in the presence of encrypted protocols to be available on a wider scale, so like basically, truly end-to-end on the internet and one of the things that would immediately prevent it is those non-optional, slow mon id could be considered by many people as a privacy uh concern, and it looks like in at least context of transport protocols that provide flow identification themselves.

I

uh Some people could consider it's not necessary to be mandatory. uh So that's one comment. uh The other comment I have is that we call it lost bit. It should better, be called upstream loss bit and uh we pre in our draft that we presented in tsvwg. We actually provided also additional bits for the downstream loss information.

I

um It would be a good complement uh to release that uh to specify that additional downstream bit, uh so we have a tsvwg drive that basically shows how to do it for any generic uh transport protocol that actually keeps track of losses.

I

So that's basically my comments about this. Thank you.

H

Okay, uh yeah. Thank you for your comment. Firstly, uh regarding your last words, I think that uh the in this case we don't have round trip measurement. So this is uh one direction measurement, so it does not make sense to define upstream loss beats or uh downstream loss bit, because this is just one direction. So it's a point to point measurement in this case or point to multi-point, but only in one direction.

H

So if you want to make two direction you have to to couple uh by yourself, so the controller can do that, but for ipv6 it's just one direction like the base, rfc8321 and multipoint ultramark draft. So it's not by direction so giuseppe.

I

Yeah, sorry, let's stay with this point for a second, uh I would recommend you to review our draft, because the upstream outlaws left us bit lost stream. A lost bit is also reported in the same direction as downstream loss bits. So it only requires a single point to multiple. It's only one single point to multi point. So it's not you don't really need return. uh Any uh return traffic. It's the same sender that say sending alternate markings is also sending additional bit that.

E

Is basically controlled.

A

I

A

I

I didn't invite you to read the draft again.

A

Okay, so can we can we bring the rest of this discussion to the mailing list? We are over time um and we do need to manage the time carefully, because the meat echo session will end quickly.

A

We have a five minute window to go over, but after that it will shut down. So thank you. um Why don't we go to the next presentation.

C

Fernando you are up, let's see if we can get your audio working, okay, ferrando! You should have audio granted.

C

We cannot hear you um okay. Now we can hear you, I think, okay, okay, perfect, perfect,.

J

Yes, go ahead. Okay, I not seen my slides on the screen is that okay.

C

Oh, it seems like yeah. Let me stop and start that again and see if that helps.

J

C

Oh, it's just one tab at a time: yeah, that's slightly broken! Okay! Now you can.

J

See them ah that's perfect, awesome, awesome, okay, um so I'm fernando and I will be presenting the document on um improving the reaction of ipp6 like to flash renumbering events. Before I start the presentation, may I ask the question that I was going to ask before when I, my audio, wasn't working.

C

Yes, I guess you can try quickly. Okay,.

J

So my my question comment was that um you know, while you were um describing the result of the consensus process, um you mentioned that there was a consensus or agreement to you know, work on a problem, but not on on the solutions, and um you know I went through the comments through the main list and um there were say two three um comments with concerns about one specific section on um you know of the document.

J

But um you know what I've seen so far is that there wasn't, uh uh let's say, objections against against the the rest of the document like in any case. um So that was my my comment so to speak, and um in fact, when it comes to you know some of the you know, objections that were made. um You know the ones that I remember were kind of like vague, like okay. Well, this this is.

J

This will make slack fragile, but you know when I asked it, for you know clarifications on what specifically they meant, because you know it's hard to agree or disagree with a statement that is vague like uh well. This makes it fragile without providing, like you know,.

E

J

Where things might break so that was my problem, but in any case I you know during my presentation now we can. I guess we can focus on each on the topics and if people have concerns they may raise it, they may write them.

A

Good, I mean what we, what we would like to see is discussed here and then on. The mailing list is proposal for for specific text in each subsection, and then we want to see the working group response to that. Okay.

J

A

Of them shouldn't be an issue.

J

Fair enough, can we move to the next slide? Awesome. Okay, um so essentially this document um you know, tries to mitigate the the or try to improve, tries to improve the reaction of slack to flash renumbering events, and we try to you know, improve things um you know in different areas.

J

um One of them is to employ more appropriate uh prefix lifetime values. uh The other area is that we try. um We propose some tricks to slack, so that um information is is delivered or transmitted in a more in a timeline manner.

J

And uh finally, what we try to do, which is, I guess where most of the you know, concerns or objections- have have been- um is a mechanism that tries to um find out when information has become stale. So um what I'd like to do is I will go through. You know each of these three areas and after each of these three areas we might you know, might get comments from you uh so that we don't have to discuss the whole thing.

J

You know all together uh next slide, so um the first one is about the prefix information lifetimes. So if you look at uh the spec there's a default value of one day for the body lifetime and there's um a default value of uh of sorry at full value of uh one day for the preferred lifetime and a full value of one month for the valid lifetime.

J

So that essentially means that you know these timers will will never go off in any meaningful time frame. So uh our proposal is essentially to change these timers um as a function of the router lifetime. So specifically, uh what we say is that the preferred lifetime should be set to the same value as the router lifetime.

J

Obviously we are not talking for the case where it's a non-zero value and that the balanced lifetime should be a multiple of that uh could be, for example, three times that which is you know the normal thing for for many rfcs.

J

um This obviously doesn't completely solve the problem that we have at hand of course, but uh it does help in the sense that you know still, information will be deprecated even if a router goes away or will be eliminated in a more. You know, timeline manner.

J

J

So the what we, what I just described of course, is a change on the router side. Okay, now, obviously the let's say the limitations are the problem with. That is that you know in order for that to take effect like widely speaking, then you'd need every router to be updated accordingly. Okay and in you know in the you know, near or long term, that might be acceptable, but not in the shorter term.

J

So the other thing that um we are in the document is that a host that is on the receipt side of slack they can cap the the lifetimes of the prefix information options, with the same logic that we described in the in the previous slide.

J

So that means uh if the prefix, for example, if the uh preferred lifetime value that a host receives it's much larger than the router lifetime, then the host would nevertheless use the router lifetime value as they prefer lifetime. Okay.

J

Similarly, for the valid lifetime, that would be a multiple of uh the router lifetime.

J

uh Of course uh there is um this should only or or there is specific cases where this shouldn't be applied, which is when the router lifetime is set to zero, because that's a special value that essentially means don't use this router as a default router. So it wouldn't make sense to to use that value.

J

uh You know to set the pr to set the prefix lifetimes and the other two cases is when the lifetime value is set to all f's, because that's infinity, so you know, potentially there could be a system that is setting a prefix to infinity. That means you know you should use it forever either. Even if you don't hear from me again um so that's so far when it comes to using the more uh appropriate lifetime values for the prefixes router side in the previous slide and hot side in this slide.

J

So I'm wondering if the group has any comments on this.

B

Dave go ahead, dave taylor. um So since I haven't looked this recently, your slide looks okay to me. As long as one thing is true, can you confirm um when you have like multiple routers? um Is it the case that the host only ever extends the lifetime of that state and never reduces it? So I'm thinking of the case where two routers are advertising different, say router lifetimes and what happens to the prefix lifetime. Is it the max of the two?

B

If you just confirm that and also there's a case where one robber is actually counting down to zero, because it knows it's going to be reset say an hour from now, and so it's constantly counting down and in some implementation, but it's not quite zero yet, and so, if you can just confirm that it's always the maximum, then I think your spot is fine. So.

J

uh We I think we underspecified it in that respect, but certainly uh we should be explicit about that and use the maximum. As you say,.

C

So yoshifumi are you intending to enter the microphone queue because you asked to share screen and video uh if, if so enter the audio queue instead, otherwise will decline. You go ahead, fernando.

J

Okay, so let's move to the next one: okay, okay, uh so the next. uh The next group of mitigations that we were referring to was that of having information, be conveyed or transmitted in a templar manner. uh Next,.

J

Slide there you go so if you look at um rfc 4861 in section 5.5.3 item e, essentially the rfc says that if you get a prefix information option with a lifetime with a valid lifetime value smaller than two hours, you should essentially disregard it or to put it in a different way. You should never reduce the lifetime value of a prefix in response to a pio option to a value smaller than two hours. Okay. Now the reasoning that the rfc gives is that that would be another that that could be considered an attack vector okay.

J

So, by refusing to react to such a pio, then you are in a way mitigating you know that other vector, but you know from our perspective. um Essentially you have so many different attack vectors in slack that either you know you trust ras or you don't or to put it in a different way.

J

uh You implement first hop security or you don't from the perspective of fanatical. uh You know, even with this mitigation in place, you could do uh neighbor cash poisoning. You could disable rudders by spoofing packets with a rotor lifetime of zero. You could flew uh the horse uh with uh rios and pios like as many as you want. You could cause nodes to use a hop limit of zero one or something so that all of their packets get discarded.

J

So the point is that you know from our perspective it doesn't make make much sense. You know to try to mitigate one particular vector when you have so many others now, on the other hand, um this specific item in 4861 essentially prevents prevents cases where you have a router. That knows better that you know a prefix has become invalid, um and this item in the rfc essentially prevents the router from signaling that connect that condition to the host and, in particular, for the host to react to that condition.

J

Okay, there are, you know, multiple cases of that they are good. You could have a cp that you know is using a backup connection, now switches to the main one. Now the traffic has changed. The router knows that the traffic has changed. It could signal they could the condition, but you know this item in the rfc will prevent horse from reacting to that.

J

So our proposal is essentially uh essentially remove that specific section or you know, modify it in a way that costs will react to all body lifetimes, including valid lifetimes, that are smaller to two hours. uh Next slide.

J

This is also in the same area as you know, trying for information to uh you know to be spread in a templar manner. um Essentially, if you look at uh section six dot to the four from rrc 4861, uh the rfc says that you know in cases uh when an interface becomes an advertising interface, meaning that you will uh start doing slack with that interface of the rudder uh the router may transmit up to blah blah blah and solitude and unsolicited advertisements. Okay.

J

Now our proposal is to change that may to a shoot. Okay, uh and the idea is quite simple- that you know whenever the information has changed in the router, you really want that information to be spread in a timeline banner. Okay, um besides the discussion that um we had on the mail list, uh we also had some off list discussion with a number of folks and um chen suggested that so right now, the document uh specifically proposes the change that we have in this slide.

J

Okay change the may to assured, when, uh for an interface that becomes an advertisement interface now, jen has suggested that we probably should recommend this too for the cases where the information that is to be advertised changes not only when the ugandan interface changes from non-advertising to advertising interface, but also when the information has changed.

J

So any comments on these past two, that of um reacting to pios, with a small valid license, or this one about interface, initialization.

C

No one jumping.

J

In front of the microphone as far as we can see, okay, so I will go on and in any case, in the you know, by the end of of of the presentation, we can discuss any remaining remaining items now.

J

The last group of of the mitigations that we have in ide in the id is section uh 4.5 or what or what was section 4.5 in the individual individual version of this id, and it is essentially an algorithm and a mechanism to try to detect when information has become stale and, in those cases, try to deprecate it and subsequently invalidate that information. Okay.

J

So um as an overview of the document in the of the of the mitigation in the next line, I will go a little bit more into detail, but essentially the the algorithm is composed of two different parts. Okay, the first part is the trigger okay. In with situations in which scenarios, what are the things that that causes a host to try to verify or or check whether information has become stale?

J

So what we do for uh the case of prefix information options, essentially, is you know the host keeps track of the prefix information options that it has received? Okay, they already do that now, if you receive a an ra that is advertising bios, but one of the previous pios that you had received before now is missing.

J

Then you know should trigger, or what we say is that that should trigger the host to try to validate whether that information, you know, is still fresh, then. The second part is the deprecation and invalidation part okay. So what do you do when um you know you think that the information has become stale?

J

What we do, what we currently do in the document is uh to try to react in a passive way in the following way, when you receive an array that contains prefix information options, but one bio is missing, then what you do is you update the lifetimes for that previous bio and obviously for the corresponding addresses and you set the pref the preferred lifetime in the order of a number of a few seconds and the valid lifetime? To a much larger I mean small value, but still larger could be.

J

You know, for example, a multiple of that or you could set it to the router lifetime, for example. Now the idea is, but it's quite simple: um if the information is fresh, then obviously these timers will be refreshed and nothing happened on hand. If the information had indeed become stale okay, these timers will go off, and that means that first, the uh prefixes will be deprecated or unpreferred. If you wish and subsequently.

C

Yeah there's a long discussion on jabber now about which slide you're on. Do you want to want me to advance to slide seven abs.

J

Sorry, yeah yeah, sorry that that was my bad uh next, uh that one yeah exactly um apologies for that. um So we have like a trigger condition. You receive an array uh that contains pios that is missing a previous pio and that triggers the let's say, deprecation or possible invalidation in which what you do is you reduce the valid lifetime and the preferred lifetime. You set the preferred lifetime in the order of a few seconds and divided lifetime, for example, to the same value of the as the router lifetime.

J

What we do of the idea of setting the preferred lifetime in the order of a few seconds, as opposed to setting setting it to zero right away, is, for the case, the theoretical case, where the information where the router might be splitting all the information into multiple arrays okay. So, rather than setting the preferred lifetime to zero, uh you know right away. We set it to a value for around five seconds, meaning that you know. If the information is split, then you know right after this array you will get the other missing information.

J

Okay, so obviously the good part of this one- and the idea of this is that as long as you implement this in a host, no matter what the router is doing, you are able to more gracefully handle the case where there is flash redundant. Okay uh next slide.

J

Okay, so hang on so.

C

We need to have a question from dave. Let's, uh let's see if we can take that slide, seven yeah, please dave, go ahead.

B

I just want to confirm that on slide, seven, if you can go back one where it says, uh if you're missing uh the trigger an array that receives pios- and this is a previous io- I want to confirm- you would mean that and to say but misses a previous. I o from that particular router right.

J

Yeah exactly yeah.

B

Okay, great thanks.

J

Yeah um and so uh yeah this one so- and this is essentially the same thing the same thing, but uh you know with a little bit of more of of detail what we do in the document and from our perspective, uh this is, let's say um an improvement over the algorithm is, to you know, split things for uh global addresses and ulas.

J

Personally, I don't think that this is really necessary, but I think that this is an improvement over the algorithm and essentially, the idea is as follows: you handle the case of uh global addresses, separated separately from ulas.

J

The reason for that is that the idea is that you will only deprecate global addresses if you have a new global address and you will only deprecate you, they still ulas if you have some sort of ula of new ula. So the idea with this specific um you know algorithm that we have in this slide is that the algorithm will deprecate global addresses only if there are fresher global addresses and all will only duplicate ulas if there are fresher ulas.

J

Otherwise, if you don't do this optimization, if you wish, then you might, you know, get rid of all the ulas and only keep let's say fresh global addresses now same as before. You receive an array that contains uh pios for global addresses, but the previous one is missing. So what you do? What you do is you set the preferred lifetime, for example, to five seconds departed lifetime to a value larger than that and again as before.

J

If the prefix is valid, those timers will be refreshed, nothing happens, but on the other hand, if the prefixes have become stale, then you will quickly, you know and prefer those those uh prefixes and addresses and also will eventually uh get rid of them will invalidate them same thing for uh ulas and, uh as um you know, they asked you before.

J

We are very explicit about this in the document that, in the case where um multiple routers have announced the prefix, instead of getting rid of the address, what you do is you disassociate the prefix with that particular router? So essentially, that's like changing the local state and saying okay.

J

Well, this uh prefix has become stale for that particular router, or, to put it in a different way, we say: okay, well, that router is not announcing that prefix anymore and now the fate of the prefix and the corresponding addresses will uh depend on what the rest of the routers that we're advertising that prefix are doing. Of course, if the prefix has become has become stale for all of the routers, then of course you disassociate the prefix with all of them, and the addresses and prefixes will get unpreferred and you know invalidated eliminated any comments.

C

So jen has a comment: let's see, jen go ahead.

C

Jen, we cannot hear you.

K

Sorry, I'm slightly confused here. So is it more or less the same algorithm you ahead in the case before the adoption yeah yeah? What we're doing is what we're doing is discussing.

K

Yeah so, like I think, we've discussed it before right. This algorithm looks a bit fragile in case of arrays being lost or information being sent in multiple arrays right and also. I do not think there are many implementations which are properly associating prefix with the with the router. I'm still not sure what would it mean for uh existing implementation.

J

So um the thing with that is, um I'm not sure why you say that um it is fragile in the case um you know, could you elaborate on that? Why you think it is fragile when you know um packets are lost.

K

So I'll take it on the list here, because I don't think I think it would be easier to discuss on the list here while.

E

K

I think uh I'm just confused, because I think uh it was a lot of uh disagreement about this particular section before the adoption and adoption seemed to be done. Assuming this section will be rewritten, so I'm not sure why you're proposing the same text again. So do you think we'll change our mind.

J

So uh what the chair suggested, if I understood correctly as part of the adoption process, is that the group would discuss each of the mitigations that we had in the document, so essentially what we did. If you look at the draft idf version of the document, none of these tags, no one of the slides that I discussed before are in the document. But essentially what we are doing is discussing each of the mitigations for people to either agree or to.

J

J

And in particular, when it comes to the section that we are discussing right now, I mean there, for example, you have made like the comment that uh you know the this algorithm is is fragile, but you know I asked it if you could elaborate on that. um You know, as I mentioned on the mainly list, uh you know a comment such as okay, this is fragile might be correct. You might be right, but you know, if you don't elaborate on a scenario where things might break it's difficult to.

J

You know, agree or even to disagree with that.

C

Okay and then we have teddy nicu. If you don't want to interject jen ted go ahead.

C

We can not quite hear you there that if you are trying to speak.

L

Now you have the floor. Actually, the issue is a browser.

C

L

About that um yeah, so so the question I had is: do we actually have any data about this, because um you know, I think that the the question that that fernando and jen are debating is actually not a theoretical question and that we could collect data and actually see you know whether this is a real problem or not, and I'm just wondering if, if this, for example, this this presentation and this draft is actually motivated by data- that's been collected, that could actually be looked at, um because that would really be helpful in resolving these questions.

J

So what you're asking is whether the problem that we are trying to solve doesn't actually occur in practice.

L

No, no, no, that's not what I'm asking at all. What I'm asking is, if you've actually formally collected data in a way that can be analyzed. The reason I ask that is because my my experience in practice has been similar to yours. So so I think that this is an issue, but the problem is that it's hard to resolve these questions without any data to refer to, um and- and I think that's the case right now- unless you have some data.

J

And when you ask, when you ask about the data, what what specifically are you referring to what kind of data? What specifically, would you like to be measured so to speak? Well,.

L

So so you could put, um you could do some data collection on devices that are connected to ipv6 networks that just notices like whether router advertisements are being missed or not whether prefixes are uh uh you know, being lost and and then, for example, implement this algorithm, uh run it on a collection of devices and see what happens. uh Do we in fact find ourselves losing pios that we actually shouldn't have lost and so forth and right now we just have have. As far as I know, no information about this.

J

uh um An additional question, when you say losing pios, you mean like if the flash renumbering events occur, whether the array, packets get lost or something.

L

Else, no, no, we know we know that if a flash renumbering event occurs that we're going to have issues like, I don't think anybody's questioning that the question I'm asking is: if you did this thing to mitigate that problem, what would happen like? Would we in fact- and you can test this already on a you- don't even have to change the implementation you could just set uh uh set up some code running on a bunch of devices on your network that just track like how often do I miss a pio.

L

If I were running this algorithm, would I lose my prefix, um and that would be really interesting and I don't think we have that data right now. This is something that I'm very concerned about. So I'm not saying you're wrong. I'm just saying it would be nice to have the data.

J

Okay: okay: point.

J

J

I think there's um are there any further comments before I uh continue? Yes, we have dave in the cube as well. Okay,.

C

B

Just looking back at 48.61 there's another case that I'm potentially worried about here, um 4861 says that you can have, and here that the question is, if I have a bunch of offlink uh prefixes right, and so it talks about how there can be multiple instances if the number of included options causes the advertisement side to exceed the link into you, the router can send multiple separate advertisements each containing a subset of the options right so consider the case where, for some odd reason you have a very large number of off-link prefixes and you split them across the ras because of this rule in 4861.

B

What do you want to happen?.

J

uh What would happen is that uh the first one that you, when you receive one of them uh it would reduce the lifetime, but then the subsequent ra will refresh the timer, and then things should continue normally, so the algorithm does accommodate the case. Where you are, you know splitting the ras.

B

Okay, I think that's right. I can't immediately see anything so it sounds like you've thought through it, but that's the one case that I want to make sure your draft uh would cover in this case that it's nice.

J

It's not on the slide, but we we did consider that case. Specifically, um I could, if you wish, um you know, uh post the specific part of the of the mitigation where we discuss and mitigate that specific case.

A

You have about four minutes left.

J

Okay, so um next slide.

J

So um here I I'm I'm trying to um you, know um uh essentially mention or do an overview of all the things that uh were uh proposed uh as an alternative to these last algorithm that I just described uh so uh philip essentially uh proposed something different. Essentially, um he suggested uh that uh the algorithm could uh sample a router and try to figure out.

J

You know if the router is splitting information into multiple arrays or not, and then uh based on that, uh you know the host would know better how to react to the ras that are being sent by the by the router.

J

My personal take on this is that you know this is more complex in a way uh and it doesn't really buy you much, but in any case I'm mentioning this uh because that's one of the proposals that were made and other proposals that were made was where to rather than try to passively deprecate information, as we do in the algorithm that we proposed uh to do something else and try to uh do some sort of active, proving there were different things proposed like trying to you know, do something with an offlinc node, um my personal, take uh or paul the router.

J

You know using uh one of the you know, one of the prefixes that you're trying to deprecate um in particular when it comes to you know, trying to communicate with with some sort of offline system.

J

I believe that that wouldn't be, um you know appropriate here, because what we are trying to do is to check whether you know the information is still fresh. Now, whether you know uh you can use those addresses and whether you know connectivity is working with some sort of offline offline system, that's like a different thing.

J

uh Next slide and last one.

J

Now um what I try to do in in in this slide is you know, for um is to to offer let's say an alternative um uh for folks that you know my that had some concerns about the the algorithm that you know I just um I just described, and um you know when thinking about possible alternatives. You know from my perspective, um essentially you know whatever we do whatever algorithm we you know um implement for this.

J

It will essentially consist of two parts like something that triggers the detection of stale information and what you do to. Actually, you know check whether the information is fresh or or what you do to actually deprecate it. A possible alternative is to still use incoming arrays. That means a bio to check some sort of you know.

J

Detection of you know of whether this information has become stale, but instead of reducing the you know the timers, you know a host, could uh you know, send a unicast arrays to the router, possibly a number of times, retransmitting it as necessary, and if the missing information is not included in the responding arrays, then you'd consider um you know that the information has become stale and you deprecate and subsequently invalidate it.

J

What we have in this slide, that of you know sending and unicast arrays does not need to be mutually exclusive with what we um would with what I described in the previous slide. So you could still reduce the timers, but in any case you could, you know, send a unicast array, a unicast rs, to pull the router directly uh and and try to get um the you know. The the prefix information in a solicited manner are supposed to be by via the the unsolicited arrays.

J

So that's another possibility that that is on on the table um if there are not um uh any uh subsequent comments. uh What I like is that for folks that you know have any specific question or objections about any of these things that we have discussed, particularly if they have objections if they can describe a scenario or what they have in mind, where things might break.

J

Okay, uh that's either to you know to find something that we missed, or you know if we think that the scenario that you are describing uh actually can be mitigated or wouldn't be, a problem you you ought to be able to tell.

A

Okay, fernando, thank you very much. I think we'll have to.

K

A

This up on the mailing list. uh What we'd like to see is you have sort of raised these issues, probably in individual emails, and we can then go forward from that. Thank you, perfect.

J

Perfect. Thank you.

A

C

Okay, so uh jen you are up. I think you have the audio already. Please hello,.

K

So uh next slightly so quick recap, I hope you paid attention, but just in case the problem we are trying to solve is actually described in another draft, which is v6 draft, and the problem is when a host starts. Sending traffic from a new ipv6 address, which hasn't been seen on the network before host, already gets all information about the default router, so it could send traffic, but when the return flow packets coming in the router normally does not have any neighbor cache entry for that address.

K

So it starts our address resolution process and meantime, most of those packets are dropped until the resolution is completed, which is undesirable because it basically slowed down the process of connecting a host to the network. So suggestion is when a host configures a new ipv6 address, let it advertise it by sending cancel list detainees.

K

The uh 2861 currently saying that if there is no entry unsolicited and they should not create them, so we are proposing to change it and say that routers should actually create a style entry upon receiving unsolicited name. So next slide, please.

K

The draft is currently in the working group. Last call. I submitted on sunday as a zero one version which integrates most of the comments I received during the last call, and it also has a few other changes. So next slide please.

K

So, first of all, I realized that the text was not actually clear because it was used, host and node terms interchangeably, while it actually should not so esther 4861 node is a any ipv6 enabled device and a host is node, which is not a router. So mark smith pointed out that the proposed mechanism could be actually beneficial even for a router. So when router creates a new ipv600, it could also announce it by sending cancellation a so as a result, I clear cleaned up.

K

The text and gift is currently using the terminology of node, so it will the proposed mechanism of sending an a will be applicable for both hosts and routers next type. Please also zero. Zero was suggesting using the mechanism for global addresses. However, there are some reasons for maybe using it for any address, including link local. First of all, it's easy to implement. Probably implementers do not need to do some ifs and else right. Just whatever address you configure sentence a list at an a and also it might be beneficial in future.

K

So currently, I am struggling to see the real scenario when it could be useful, but apparently I talk to some implementers and they believe it actually would be easier for them not to make this difference between link local and global, so the zero one version of the draft does not explicitly talking about global addresses. It's just saying: ipv6 address next slide. Please!

K

Yes, I'm two weeks old proposed updates to section 7 to 16 4861, basically, which saying that a host should send and solicit me. I just found the better position in this section for the proposed paragraph, so please review this uh section of the draft and the most important update next slide. Please it's about avoiding disruption. I think I actually mentioned that on the last interim, but I'd like to bring it to your attention again, because it's probably the most significant change in zero one. So next slide please.

K

There is a one very specific corner case when proposed mechanism might introduce some destruction in case of duplicate, aggressive hyping on the network and optimistic that being used. So scenario is this: let's say we have a rightful owner host a which has configured an ipv6 address and start sending packets before the return traffic arrives. But after that rightful owner starts using it. Another host assigns the same optimistic address. Samsung solicit an a and after that, the return traffic for the first post arrived next slide.

K

Please what happened without the proposed mechanism right in this case it will be a short period of time between receiving unsolicited dna and uh n, a from uh the rightful owner when traffic might go to the wrong country and next slide. Please it's very shorter right. What happened if router creates a style entry?

K

In this case, the stale entry will be used for sending that return traffic to second host, which is actually not the rightful owner, and in this case the delay might be slightly longer.

K

So next slide please so delay might be like it would be 5 plus two seconds it's about seven seconds in the worst case scenario, but next slide please, the probability of this seem to be rather low right, so it for this to happen. Two hosts needs to start using the same ipv6 address almost simultaneously right and the second host needs to send an a before the return traffic arrives. So basically the question is: do we care about that corner case?

K

Is it bad enough to not to proceed and do not get all those benefits of pre-populating the cash on the routers? I actually don't think so, but I'd like to hear the work in group opinion- and I think my next slide is the final one. So questions comments.

B

So today visit the q dave go ahead, um yeah, I'm just getting through the draft. uh I have a vague record, so thank you for the quick recap. At the beginning. I have a vague recollection that I may have asked a question at a previous meeting that you answered. I can't remember the answer and I was looking to see if he ends in a document and I couldn't find it there and if it's not, my request would be. Can you add the answer into the document?

B

So the question is, um if I understand this right- and maybe I don't because uh we didn't go through the the refresher uh at the beginning of this- and it was some time since I looked at this so anyway. So the question is: um does this require the host to change or only the router to change? If it requires both sides to change, then, of course you may not get deployment anytime soon until both sides change. So the the I think.

B

The question that I asked at the mike at some previous meeting was something like: have you um uh looked at some having the router do something that does not require the host to change? So, if you can just clarify, does this work with existing hosts and, if not, maybe some rationale as to why you'd require a host change? Or is this something that works with existing hosts? Just fine.

K

So thanks, so actually I think what else can we do it's in v6 of draft? Because if you remember what happened we had initially, we had the one round, which was discussing all possible things. We might do starting yeah, yeah uh and thinking careers, doing other things, and then uh the document discussed pros and cons for all solutions and so far the conclusion was: let's do this and all other options are discussed in these six songs that you can look at this and I think we're gonna.

K

If you, if you're going to publish this, they should be published together right because they're referring to each other, so the thing is first of all, as far as I know, there are implementations on the routers already which are doing this, so the thing is, and if you say should right I mean uh currently. If we take one thing: uh node should not create a new entry upon receiving unsolicited name, it doesn't say, must not so basically, by doing this you're, not even violating anything right.

K

So we are not actually changing the router behavior prescribed router behavior we're clarifying the rfc that routers probably should do this. uh Also, uh there are the only thing which you can do without making any changes on the host is to integrate data playing a control plane on a router right, and when the router sees some outgoing traffic flows, it could create a course. It could start a neighbor discovery for that address. However, unfortunately, the problem with this is, if you have two routers on the network, let's say the error p, like first hop redundancy.

K

There is no guarantee that your outgoing flow is crossing the same router as the return traffic so uh and the kickstarter draft actually discusses the requirements for the solution, and they one of the requirement is. I want all routers which can serve the return traffic to have the neighbor cache enter right and so far the only way besides actually looking at the data packets, but with that package there is the other problem. You not necessarily see that packets.

K

Unfortunately, if you have smart wireless infrastructure, so here there are different things you can do some some routers actually do some of them already, because they're not prohibited by rfc. This one is one which, where we actually need to update standard. So that's why here is a draft. Nothing prevents you from looking at this exhaust drop and do whatever else is described there as an additional optimization, and this this doesn't break any.

B

Question I think you're you're saying the answer to my question about the motivation and rationale or whatever is in the nd cash in it draft and you want them to be arrested at the same time and that's why the rationale is not copied into this one, because the other one you intend to go to rfc and the reference is where you'd find it. So I think that's three answer right questions you want to do request at the same time, okay, because what I was going to ask is: can the rationale be added to this document?

B

If the other one is just going to be, you know left or leg or whatever, but uh but you're saying no, it's actually going to go on the other one and you want to be progressed at the same time. So thanks.

C

Okay and then we had tom in the queue, but I think if it withdrew at least it disappeared in the tool uh tom. If you want to speak uh yes, okay, here, he withdrew um thanks a lot jen. It sounds like we need another round on the mailing list before we go and go and advance this document um excellent thanks a lot for the next one. We have fred templin. Let me just share your slides quickly.

A

And fred well, so we are um for the session we are over by about 13 minutes. So if you can do this in less time, it would be good if not we'll have to move ted's talk to friday.

C

Fred, you should have.

C

Audio, what about now.

M

Hi, this is fred, is my audio on.

C

Your audio is perfect, go ahead.

M

Okay, thank you, yeah bob I'll try to adhere to as quickly as I can on on the presentation. So this is the overlay multi-link network interface. This is the ietf update and status next chart please so where this document came from is that it's been under development in the international civil aviation organization working group by mobility subgroup.

M

For a number of years now, and at the uh the the mobility subgroup meeting in vienna, austria back in february, we decided to put a liaison statement forward to the ietf requesting publication of this document and uh the the venue that we're looking for for publication would be as a working group document of the ietf six-man working group next chart please so uh some status, uh we did put the documents, the ietf, the ietf requested that we renamed the document uh with six man.

M

In the the name of the document, uh the liaison statement was submitted to the ietf back in march. We did present the draft at the its six men working interim working group back in march. Also in terms of the ietf direction, the preferred approach is to publish is a six-man rfc and a backup approach would be to go for an ad sponsorship, um and then the next step, as of today, is for looking for a six million working group. Adoption call next chart please.

M

So what about the omni link that uh makes it something that should be of interest? It's a flexible virtual link model supporting rc 2473 encapsulation in rsc 4193, addressing uh it's a a link model that is for an always mobile router, with no home link and a portable internet of things with multi-addressing, and this is a 21st century archetype.

M

um It supports operation without access network configuration so that each node receives a stable and unchanging mobile network prefix, and we have stable and unique link local and unique local addresses that are statelessly derived from this mobile network prefix, and because of this mapping of the addresses we have no care of addresses and no need for mld version, 2 or duplicate address, detection, no home addresses or home link models needed no prefix delegation messaging is needed and it provides significant savings in avoiding costly, unnecessary radio transmissions now includes multi-link coordination parameters in ipv6, neighbor discovery messaging.

M

What that means is that no adjunct messaging service, such as binding updates, would be needed next chart. Please.

M

It provides for safety based and performance based, multi-link support, so each omni interface connects to a distinct safety based multi-link virtual link. Segment. Routing is used to select the safety-based multi-link interface and navigates. The the svm topology each omni interface is independently coordinated, coordinates its own performance-based multi-link.

M

It's based on standard ipv6, neighbor discovery messaging with no adjunct protocol messages, so we have rsra for router discovery and multi-link coordination and nsna for address resolution and neighbor unreachability detection, and it supports path, mtu assurance and path, mtu diversity.

M

So it supports the native interface mtu without encapsulation reduction. So if the native interface is 1500, for example, you get the full 1500, you don't get some degenerate size like 1480 or 1460., and it does support mtu diversity up to 90, 90 180 bytes without empty packet loss, and this observes the fact that fragmentation is always going to be required when encapsulating over links with 1280 mtu.

M

uh There's no way around it. If you want to send an encapsulated packet over 1280mt link, you require fragmentation.

M

Next chart uh simplify security over access networks with omni aware access routers, so the rsra messaging, the access networks between the mobile node and the access router are protected by physical and link layer security and the access router can then coordinate with mobility service endpoints in the service network via secured spanning tree over the overlay network. uh So this is a network layer.

M

Security for the spanning tree is used, um and then vpn security and secure neighbor discovery can still be supported for open internet access networks like, for example, if you had a mobile node connecting through a starbucks wi-fi or something like that um in omni supports what we're calling massively distributed. Mobility management because you can have many hundreds or thousands of mobility service, endpoints, all servings, servicing a subset of the nodes on the link, uh a single mobile note to ground rsra message.

M

Exchange could also be used for significant savings in all over the air control messaging next chart. Please.

M

Okay, so because of the omni link, 2473 encapsulation and 4193 unique local addressing any mobile mobility service endpoint can service any access links. So uh in the aviation domain we have many network service providers uh there. There are corporations known as ceta in marsette and air inc that all provide internet working services to airplanes.

M

So we can have it such that a mobility service, endpoint living in one operator's domain can service the links from an aircraft coming in through another operator's domain, and the omni interface connects the mobile node to the omni link and allows multi-link coordination through a common mobility service endpoint, even though there might be multiple service providers.

M

The omni interface also provides for nat traversal, using the same encapsulation format and bubble messaging. As for rfc 4380, and then we have the penultimate hop towards the final destination, can use segment, routing and encapsulation for route optimization next chart. Please.

M

So omnilink local addresses are created by taking the mobile network prefix assigned to the mobile note. For example, if the mobile network prefix was 2001 db812 64, then the omni link local address is formed by taking fe80 in the top 16 bits and then concatenating the 2001 db812. As you see there in the boldface, that's how you form a link, local address, an omnilink local address and then the omni link local addresses are easily translated into omni, unique, locally link, unique local addresses and vice versa.

M

M

So what the omni link is is a virtual link model again using rfc 2437 73 encapsulation that forms a a layer 2 spanning tree for spanning one or more inner networks. Now I mentioned before about the omni unique link, local addresses and they're taken from rc 4193 in a one-to-one correspondence with the omni link local addresses.

M

So, for example, if you have the omni link local address this fe-802001 dba one two to get the omni uniqlo local address.

M

All you need to do is clear bit number six to get fc80 colon, 2001 db812, so in other words, omni ulas and llas can be converted one to another by simply flipping bit number six, and what this is doing is it's: defining a structure for the fc 80 prefix for unique local addresses in the in the context of the omni link encapsulated packets with omni ulas can then traverse ipv6 out routers, acting as bridges in the spanning tree to connect the segments of the omni link and the ipv6 neighbor discovery message can travel multiple spanning tree hops without decrementing the hop limit, and this provides us with a unique, unified, non-broadcast.

M

Multiple access link view next chart.

M

uh So, uh in terms of the aviation domain, where this came from again, there are many different aeronautical communication service providers and each runs and operates their own internetworks.

M

Airing seed and inmarsat are three examples and there will be others as well, and each internetwork is seen as a partition or a segment of the worldwide link over which the atm ips is configured and omni-linked bridges, bridges, disjoint internet works into a single un unified link with each internet working underlay as a separate segment of this bridged overlay next chart.

M

So this actually had some animation sequences. What it's showing is the pink domains are the individual network service providers.

M

The blue overlay is the omni link and what it's showing is that packets can be traversed without decrementing the hop limit over the omni link overlay between the domain, the operator domains, making it look like one big network, as opposed to many individual, smaller networks, the packets that are shown in the lower left hand corner you have an original ipv6 packet. You insert the green rfc 2473 encapsulation header that may require fragmentation, then, in which case you have multiple fragments that traverse the link and then pop out.

M

At the other side as again, a whole ipv6 packet next chart.

M

Implementation status there's at least two ways to implement this one is from a user application using the ton tap interface and a second would be through a kernel tunnel, virtual interface, uh in the same way that the linux sit and file drivers. Do it uh we're currently instrumenting the aero function as an add-on feature to open vpn and in other words, as a user application based implementation, and uh we plan to release that in quarter 4 2020.

M

We also have a custom isotap d that provides a bare minimum process context for arrow functions. That we have is another option that we could go to, but our ultimate goal is to port this to the linux kernel module and we would expect then to use the linux wire guard facility for network layer security in any case, and next chart document status plans.

M

The document name is transmission of ipv6 packets over overlay, multi-link network interfaces. It's an example of an ipv6 over food document. It defines a new ip66, neighbor discovery message: option type called the omni option and the next step would be for a six minute working group. Adoption call- and I think that's it. I think I've gotten through them all.

M

Yes, I'd like to say that this deck of charts is actually quite large and I'd welcome people to look at the deck for the backup materials, because there's a lot more details about what goes on here, but I'll stop there in the interest of saving time.

A

Thank you, um fred. um We we oli and I and eric, have been discussing how to proceed with this it. It is a lot of things and we're not sure how much interest there is in the working group. So our current thought was to solicit on the mailing list to see if there would be people interested in participating in a design team to work with you on this.

A

You know as part of um doing an adoption call, um because I I you know, I think, there's a number of separate areas here and I think it's going to require a lot of detailed work and we we're not. You know we're not seeing enough traffic on the list, as is so. That was the approach we were thinking about.

A

So it um so, I think we will proceed that way unless we hear otherwise.

C

Any other views on that.

C

Eric you had a mic eric go ahead, we cannot hear you, we can see you talking.

E

Yeah wrong button so just to confirm what we discussed with bob and who lay there and by the way it looks like the document has changed since the last time. I read it in december or january, so we need to review it. My concern is that it's a document having a lot of things inside that's a back having multiple bags inside uh and document is quite complex, so fred, is there any chance that you can?

E

I mean separate a few things out of this document and making sub documents. For instance, the mt1 encapsulation.

E

To make things easier to swallow.

M

Well, uh my my reaction to that eric is that we already kind of do have it separated as two separate documents. The interface spec is the omni spec itself and we also have the mobility spec, which is called arrow, that we don't have as topic for discussion. So we already do have document separation. We have functions, separated out. um I I. I really believe that all the pieces that are in the omni spec need to be there. um uh So that's that's. My reaction is that we already do have a document separation.

E

Okay, I need to review the document to be honest on this one and we can proceed to the deduction call I mean if bob and olay agrees- and we see what's happened right, we need to get people.

A

Reviewing and being authors as well so so I think we we will work on that um later in the week.

A

Okay, good, thank you. Fred.

M

C

Okay, excellent, so we have eight plus five minutes for ted. Let's, let's try to run that through and then, if we run over, we can do the rest on friday. Is that okay, bob.

A

C

And ted you are.

C

ah See I think you have audio, please go ahead.

L

Can you hear me we can hear you okay, so uh what I'm presenting here is uh some work that I've been doing uh on uh the problem of attaching stub networks to existing infrastructure networks. There's. This is not necessarily 100 a um uh six-man thing, but there's some really interesting, six-man related stuff in here. So that's the reason I'm presenting it here. um That means I'm gonna be saying a bunch of stuff. That's not actually six-man related when I describe it, but please bear with me so go ahead to the next slide.

L

Next slide. Okay, so so uh the common flow we have here is the host connects to the network next slide, and uh then it discovers internet servers using dns and it can communicate with the next slide.

L

So, basically, that's like one of the things that a host can do when it's connected to an infrastructure network. Next slide, I'm just giving this as background for what I'm trying to do with the stub network. So again we can discover services on the link using multicast, dns next slide and then once we've discovered, then we can communicate with them next slide.

L

uh We can discover the so if, if I have a device that I've connected to an infrastructure link, it can be discovered using multicast dns if it's advertising any services next slide and we can communicate with it directly because it's on the local link next slide.

L

So the new flow that I want to talk about is suppose we have uh something that we want to connect to an infrastructure network, but it's got a whole network behind it. Now. What do we do? Can we do that?

L

Do we have a way to do that next slide, so the picture here is: we've got pretty much the same scenario we have stuff we'd want to be able to communicate with cloud services, devices that are connected to the infrastructure, but now we have a stub router, that's connecting directly to the infrastructure and behind that stub router we have some number of stub devices that want to be able to communicate in the same way that I just showed you in the previous slides.

L

So the stub device wants the same access to services that the uh that a directly connected device would have next slide.

L

So um we know how to automatically connect individual devices to infrastructure, how to discover services, how to connect cert to services across the internet. um How to you know and so forth, all of the stuff. We know how to do from an individual node next slide.

L

How do we do that from a node, that's on a stub network, so uh the usual way that this problem gets solved is with nat. Obviously, that's not what I'm focusing on here. What I'm focusing on here is is suppose we actually just wanted to use ipv6. We want all the good stuff that ipv6 gives us like end to end connectivity and things like that. How do we make that work?

L

How do we automatically connect a stub network to the infrastructure? How do we connect.

E

L

So forth once we're connected, how do we do routing next slide?

L

So um there are a couple cases where I think this is interesting. One of them is where you have a device like a mobile phone that has some other ip devices behind it, that it's that are using it as a router and it would like to be able to access services that are on the local network. I mean this.

L

This this device might actually be um already connected to a cellular service or something like that, but maybe there's a printer and some device like your watch or something wants to talk to the printer being able to go through the phone to talk to the printer would be nice. Another example is a constrain network, so iot that sort of thing you've got an 802.15.4 network.

L

You can't connect 802.15.4 devices directly to the infrastructure, because uh there are performance issues, so you can't just just do uh layer, two routing, uh sorry later layer, two, uh you know you can't merge the networks so and, and the other issue with with iot is that you might have multiple stub routers connected to the same stub network. um So these are kind of the problems that we face when we try to connect stub routers to networks uh next slide.

L

um And then the thing, the thing that that uh is really key here is what I'm trying to come up with is something that would allow us to do this on existing networks.

L

So we can't assume new functionality on the network, because if we assume new functionality on the network that has to get deployed- and we all know how that looks right- we all have watched the home net. Experiment and um homenet did some really cool stuff, but you can't buy it. You can't buy a router that does home that, um if, if you could buy a router that did home net, this whole problem wouldn't exist, um but you can't. So how do you connect to suppose you have an existing ipv4 network?

L

How do you connect a stub network to that and get usable functionality? Suppose you have an existing ipv6 network? How do you connect to that? And then you know, you've got commercial networks where, where there might be dhcp service- and there might be- you know- complicated routing and infrastructure services and then you've got home networks where everything has to happen automatically.

L

L

So uh when I'm, when I was trying to make this work, what I was trying to do is figure out like what would I have to put on a device on a stub network device in order to um be able to get uh ipv6 service or to be able to communicate with devices on a stub network? In the various scenarios that I described and what I came up with is uh if you've got an ipv4 network, we can advertise right.

L

We can advertise ipv6 service on the ipv4 network. It gives us reachability devices on a stub network. It does not give us cloud reachability on an ipv6 network. We can advertise another another prefix, that's reachable through the stub router may be able to get a prefix from dhep v6, um and so we actually have a lot of tools that would allow us to to do ipv6 routing to a stub network, but we haven't really put them together.

L

L

So um so, if we want to solve this problem, I mean the obvious thing that we generally do is use rfc, 1918 and ipv4, but that doesn't work for six lowpan and it makes it very difficult to connect from infrastructure to devices. On the on the stub network. We can use ipv6 nat and that allows 6lowpan to work, but again it's hard to connect into the infrastructure, sorry from the infrastructure into the stub network.

L

um So uh if we have ipv6 on the link, then then it's it's not so bad. We can create a ula uh and we can advertise the ola on the stub network. We can advertise reachability on the infrastructure and now devices that are on the infrastructure can talk to devices that are on the stud network, but devices that are on the stub network can't connect to the cloud because we we're using ula.

L

uh If we have prefix delegation, then we can actually get a prefix that'll work on the stub network, and now we can connect to the cloud, but that requires some degree of managed network or some automatic stuff. That's not currently specified in the router requirements document so and then uh you know. If, if you want to solve a number of cases, you can get some of the functionality you need by providing ipv6.

L

So you can connect into the stub network, but you can also use ipv4 rfc 1918 for net connecting to the cloud with that 64, so that six low pan nodes can talk to the to the to the ipv4 network. So this is kind of a mishmash of stuff, but the the key implication here that I wanted to get across. uh You can go to the next slide. The key application here that I wanted to get across to the next slide.

L

We don't need to talk about discoverability, so let's go to the next slide, um so the the the thing that I wanted to present to six man is uh in order to do this, we're taking advantage of some stuff. That's not widely used right now, we're using router advertisements with uh router information options in them and router lifetimes of zero, because we don't have a default route.

L

Stub network router is not providing default route so um and we're probably using short lifetimes, because these are things that may come and go right like uh if it's a if it's a personal area network and it's my iphone well the iphone. If it advertises a route, you don't want that route to stay around forever. I mean nobody's going to try to connect to the route if they're not using it. So it's not creating a problem, but just in terms of neatness you'd, rather that didn't stay around for a month so um anyway.

L

So so uh that's the problem. um I think that this is I'm gonna probably try and pursue this in um in int area, but I wanted to get this stuff on your on your radar on this working group's radar, so you'd know what I was working on here and there's a document that specif that describes all of this in great detail. So let me see if there are any questions now, assuming we have time for any questions at all.

C

We have, we have three minutes until a hard stop and, alternatively, we'll continue throughout the week uh on the mailing list, and- and you know, if necessary, we could talk about it on friday, a little bit as well, but but yeah. If any questions now, please jump up.

C

I see no one, um yes alexander and me real.

A

D

Do you hear me? Yes, yes, okay, hello, so no much time left, but one quick question on this ipv4 target. Where does it come from? um Why.

L

The reason that ipv4 even comes up here is because there are still, unfortunately, certain people in the world who do not have ipv6 native productivity on their home network, and so we still need to make that work in principle. Now in practice um you know for the iot case. You may not even need ipv4 connectivity at all, because uh you don't need to connect to the cloud you can just operate stuff locally in the home or in the in the infrastructure in the building infrastructure.

L

So you don't need cloud connectivity in that case, but in the case of uh uh devices that do need to connect to to cloud services, then we I think it's necessary to assume that ipv4 is the way to get there. In some cases,.

A

All right, so we are about 45 seconds to go, so I think we wrap this up and thank you all very much and we will see you on friday, so have a good itef week.

A

A

Gonna wait and see if it shuts.

A

A