Internet Engineering Task Force 105, 23 Jul 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF105-INTAREA-20190723-1520

Description

INTAREA meeting session at IETF105
2019/07/23 1520

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

A

How are you, sir,.

A

B

C

Everyone so we're going to get started creation see all.

D

Your conversations.

C

C

Hello, everyone so welcome to the interrelation.

C

Great thanks, gamez, that's good!

C

So welcome to Montreal one word of advice, Seaforth room and then you can start in English, we'll get you through in Montreal, that's the homes.

C

E

Cardozo Higa.

C

Cooks was seen every turn and this is another well I guess most of you know it, but still a reminder to you that we participate and you agreed to follow the ITF processes and policies that all that we're saying is being recorded. And if you have any questions or want more details, please check the details so.

F

The minutes are taken, the.

C

Meeting is recorded, the presence is lots of bushes are going around. Please write your name. Can we have someone helping us with the her path?

C

C

It was really very kind and very good at notes, but we have a help from someone else. I'm taking notes it's an easy meeting. We don't expect much debate, just copy-paste agenda, good, some, no yeah. Anyone.

C

Scribe for the inner path means.

C

We do need some ascribe to of the meeting so.

G

C

Wants to be volunteered.

H

C

H

C

Thank you. Thank you. So tell me with backup great so Jabbar we have someone for gathering.

C

Someone that can related question is from Jabbar these things entering great, so the agenda this time. It's actually a light. One will give you the detailed update. Then we have Tommy percentage so we'll meet back up on their own notes. There, then we have Ron that is going to talk about the IP protocol. Second,.

I

Routing Vladimir.

C

On sock protocol and these guidelines and registration procedures or interfaces that infernal right any bashing or any comments.

I

C

Agenda hearing none we'll move on to the chairs update, so we have two drafts now on is G valuation. Ip fragmentation consider fragile. So it's right now the very last steps and is geometric about evaluation and also the little gooey we have it there. Some revisions needed, but no more major things, so no publications, but at least two drugs at advanced.

C

So without further ado, we can move.

A

Did you track your sings? We will start right.

J

K

Yeah I wasn't actually able to get on Dave Drucker.

K

K

So I'll be sharing our updates on the provisioning domains, draft that we have here in int area. It is actually in working group last call. We didn't get a ton of feedback, but we did get some very good input from Ted Levin, so I want to cover what were some of the updates.

K

We have in version o 5, which is the most recent published version, and a lot of these were in response to the sector review that we got and then I also want to cover some of the points that were brought up in the most recent review during the last call from Ted. We are currently in progress on building a oh six version, and what I want to do here today is get feedback from the group on some of the changes and decisions that we're making based on this feedback validate.

K

That is what we want, and if we are happy with it, we will push a new update very shortly. Hopefully this week.

K

So, to start out with the updates in version of five, so I think some of the overall feedback that we got from the second review is just kind of needing more clarity at the beginning, through the intro of the use cases, how provisioning domains and discovery of multiple provisioning domains is really enabling a user who's on a network connected to one Wi-Fi router, to be able to discover multiple up links and what is the actual user scenario driving this, and what are the security guarantees or lack thereof?

K

So we added a bunch of text for more user examples here.

K

Additionally, we had some modifications to how we are doing the PVD additional information and, as a reminder, this is the extra information that we get back. Once we've already learned that PVD exists from the RA, we can go fetch other other properties about it. This had previously been using a X scheme that is not recommended, so we said, don't use that use a vendor game, and we also clarified much more about how the ini registry and review would work for keys within this JSON object.

K

We also registered the media type for a PVD JSON to be more explicit about what type of information this is, and we also clarified based on I, think some feedback from Eric Klein, the header values that we need for nested Ras and we cleaned up some of the text there all right. So that's what we already have that was in the last call version of the document. So based on the review, we have a number of pending updates.

K

Some of these are just editorial, so I can just cover these here, they're, not quite as interesting and for reference. This is the URL that we have of the document on github and if you want to download the slides and go follow that URL, you can look at our current pull request. You can comment, you can tell us what is good or bad about the changes that we're proposing and that'd be very much appreciated.

K

So, as far as the editorial changes we're doing, or shortening the abstractors a little bit too much too wordy for an abstract and we are expanding the introduction a bit improving the flow based on some feedback from Ted and clarifying some of the examples.

K

We also added some more examples into how ipv4 the adage to be before is kind of coexisting in the the world of explicit pvd's. This was already somewhat implicit in the text, but it wasn't really explained how it would work in practice. So to cover this, the thought is. If you have two different up links, let's say a Wi-Fi provider and a cell provider, only one of them is going to be providing useful, routable, IP v4.

K

All the way to the end client, if I have source address selection for both so I would be able to associate one of those explicit pvd's with the DHCP v4 and any additional information. Let's say, the the service is offered by my Wi-Fi service that I discover from that pvd's additional information. Those could apply to the Associated v4 connections, whereas the other link would be forced to be v6 only in this case.

K

We also updated some of the references to how you handle case insensitivity comparisons for the fqdn for the PVD ID to just refer to how our c 43:43 does it, rather than trying to explain it on our own, which was not the best way to go all right. So that's editorial updates, so these next ones are more content changes, and so these I would ask if you have an opinion on. Is this the right thing or not?

K

The right thing please do come up to the mic for each of these just give us a sense of if this is the right direction based on the working groups. Thoughts. So Ted pointed out that the way we were specifying the coexistence, integration of dhcpv6 information with pvd's and with multiple pvd's that come from Ras was not correct. It was not really well thought out and it didn't actually work. This is largely because I think this is not one of the major use cases of the striving this.

K

We just need to make sure that there is some consistent way to fold in this information, something for the client to do so. We had some discussions and thank you to Eric, Lyon and Lorenzo for giving some guidance. So, let's see if this is kind of what we think we should do. What I have in the pull requests currently is specifying that if you do have a DHCP message that does include addresses and prefix that's giving out to.

K

If those do match a Pio that came from an RA that is defining a PVD, then you can associate that information with the PVD that you have either implicitly or explicitly.

K

If there is no Pio in your RA or if nothing matches this dhcpv6, then that is essentially a separate, implicit PVD interface. You cannot treat it as belonging to anything else.

K

It's just kind of off on its own, and if you have stateless dhcpv6 information, something that's not associated with an address or prefix, then we just kind of associate that with any of the implicit people T's on the interface, which is essentially the existing behavior, just treat it with the the implicit configuration for the device, but it's not necessarily associated with new explicit configuration, that's coming through the RA. So is this a viable resolution to this problem?

K

E

Is like dodging the problem and putting it and moving the problem to where we have to when you know one, we need to select the PD, because it's easy to say well, I, don't know where to put this I'm, just gonna put it in its own box, but the problem is, if, let's say, I want these 56 only network right which okay but yeah.

J

H

Disagree: six only network.

E

And there's no Pio so go to address and I've got it full route. Okay, so that default boot came from the RA. There's no containers, there's no Pio. Everything is off link, and so those should actually go in one PVD, because there's otherwise there's no people, there's no single PD that I can select. That will actually give me any connectivity. Do.

K

You want this to be compatible with an explicit PPD, or is this just to manage how I connect to things like.

E

The PVD and what's the PVD for right I, mean if it's only about the stack sort of like associated bits of things to each other.

L

E

Fine, if I can't select something that's gonna give me you know. Connectivity then doesn't seem very useful. So that's.

I

What I'm saying it's.

E

Obviously, like internally consistent it'll work, it's just like one doesn't turn out to be very useful thing. I.

K

Think, in that case, I'm imagining just kind of falls into the existing behavior for devices, and you just use it as an implicit local.

E

Braddock's request succeeds: you know ten seconds after so dear now about this implicit PVD. You know I'm gonna fall through now. Everything.

I

On this integration.

E

Is now also in this implicitly, we need, even though everything else was containerized wasn't.

K

Isn't the current.

E

E

And now so look I got an NTP server.

I

E

Dc v6, oh dear now you.

I

E

D a great and so now that these.

E

K

Think Eric wants to say something but Ted go for Tatia.

M

So it just occurred to me when you, when you read that last item, that actually it doesn't make sense for stateless to only be associated with implicit pvd's. Stateless actually have a clear PVD that we can label it, that we can associate it with yeah. It really applies to every okay.

J

You can say that.

N

Eric Clint, so if you didn't have a Pio to match addresses you got, you could easily have an REO that covers it, and and then you know that it's operationally you could say this is require yeah. Okay, you know if you're, not gonna, donor pio, because you don't vio and you can put an RA. Oh that's a /tt cord that covers the addresses you kind out and then you can identify that. That's the explicit PVDF combined with and then on. The second thing I was gonna, say: mm-hmm I think there would.

N

There obviously will need to be some kind of operating system. Api awareness to discover that there's these PBM, some implicit, some explicit they had information and nothing prevents you. Nothing prevents an application for mixing and matching information, mister hoping for the best yep right, the PPD's are there to say this is a consistent set of information. Is.

K

Where we can guarantees.

N

N

Don't work correct right, we might work so you could say or I learned about an NTP server. It's not part of any anybody, but it's part of an implicit PVD I'll, give it a shot. Yeah.

K

Good point also, if you have thoughts on that, if you could write those down as like a comment on the PR or suggestive text, that'd be great. Thank you.

O

When it's very same what matches right, so it says like addresses and prefixes match.

I

Yeah, so if I got.

O

A slash 48 in a I APD right, which will do mass like a slash 64 in the CIO right like, but it's like a subset right, so like I'm. Just trying to understand, like you know, would be mean my man so I think there's like a bit more description required because I think it doesn't match in my head. Can.

I

You man, it looks like.

O

A foo slash, 48, coming in I APD, another thing who ABCD 64 yep right: it falls another 48, but I don't think it's alright.

K

So we want a one-way inclusion.

O

And stuff like that right, instead of saying that prefixes and whatever, because we don't know what's going to be defined for these TV sets right. So that's how go into specifics. The specific TV options.

E

Feel we should try to be better than this I'm, not quite sure how but I mean. So you know one one thing that we do today right is: is we use? You know, 6 7, 24, sorceress selection and it sort of knows how to do this. Mostly it sort of looks it's what some huge face and it's like well, this is what I'm gonna do with it. It comes up with things that it thinks are likely to work and.

I

E

Know, that's that's you know, maybe in the absence of our information, it's like literally, if you're on a TV, 6 only network, then like there's, no other information, that's workable, then to use default route that you go from the RA and the AP address that you have right so I think in the real world mm-hmm.

E

It's actually gonna be a lot more common that the configuration is gonna work, because, no matter how smart the host our hosts are, the network is still gonna have to contend with those that aren't smart, and so it's probably gonna have to make those work. Somehow so I don't know how to write this in the draft, but yeah, but I do think. Maybe we should maybe I wonder if we could say look.

E

You know we're gonna open up the implicit interface PVD and linking essentially, if, unless everything is containerized, we would just put you know we just upgrade. The interface implicit PDD was with stuff. That is controller I store, something I know an MPI you by the way, I think I think it's fine to say configuration error because the Piero can have no flag set, in which case I think it's in currently foetidus Justin, Noah thinking.

I

And really does.

E

Nothing if you say a 2-0 l20, it specifically you're, saying configuration error, for which case in the case where you have you know, that's that doesn't match any PIOs yep. You just say it's a configuration error, the thing that was upgraded in the network when the PVD was added yeah.

I

E

Thing that was configured to add the Peabody I did.

I

It wrong fr a has.

E

To then add a Pio and that Pio can have zero flag set, which means it'll. It won't touch any hosts in any way. It won't affect anything yep.

M

I'm too confused to say what I was gonna say all right. So I don't.

K

Ask people who have comments and thoughts if you could just kind of add those comments to the PR here, so we can make sure we incorporate those and we can go back and forth on text. That would be great. Thank you for this input. I think.

I

This is going to.

K

Be the most nuanced parts to get right? Do you have some gory.

I

K

All right so other changes I think they should be less controversial in the additional information. Ted pointed out, quite rightly that the fact that we had a name and localized name and error. While those were cute, they are concerning not really clear how use them potential security, vulnerabilities or attack surfaces for spoofing, so I have removed those, and we are now just including the fqdn identifiers, which is the identifier of the PPD within the JSON.

K

It allows you to validate that this is indeed the correct configuration, and it essentially gives you a convenient way when you receive this PD information to say oh yeah, and here is the identifier for the rest of this stuff, so that's easy for an application or the system to consume.

K

Just this makes sense to people you have nods. Does anyone have a problem with this great okay? Moving on, we also expanded some of the security considerations.

K

There are points that we're just missing references and missing some explanation, so there's validation that we have when we look at the additional information to validate that the prefixes match the prefixes that you or have been given kind of explained, that a little bit better, there's also some test texts about how a device could try to intercept things and run a net 66 to make it look like it is providing the prefixes that are detailed in the additional information and so allow a client to think that they're talking through the real router but they're actually have an intercept in the middle.

K

This was explained in the mitigation was explained, but it was not super clear. So we reworked that text. The safety here is that the server that's actually running the initial information can validate that. The client IP address that it's getting is within the current within the range that it gave out and so can validate that there is not some intermediate net6 fix there and there's also just some text. We got at the end to really make explicit that what we're giving you is not a. This is a safe trusted, Network guarantee.

K

This is really just about detecting if this is a intended non misconfigured set of information to have two different networks coexisting at the same time. It does not really add any more trust than you would have on your Wi-Fi network today.

K

So those are the main content changes. I think the main one we need to continue working on is dhcpv6. Once we clarify that, we would like to publish a no 6 version and then get some more review, and yes, please other input.

P

New issues, none of those three, but it was mentioned on your slide 3, which was the current yeah spike tube. Sorry, maybe it was right someplace anyway, ok yeah. We have.

H

L

The media inside.

P

The document right now it does not contain any rationale for using Jason's that format the additional information in the United key industry people would argue. We got secret parsers in our devices, but we don't chase on parsers. Can we get this intervention, so you should either argue this information is something that constrained devices do not need. That would be one rationale or you have to argue and they need it so much that they should add a JSON parser or you should say, and here's how you could do it. Let's see one well.

I

P

You took the letter up from the last of three approaches which I'm not necessarily arguing before I'm saying you got to pick one of those three order, the last one. That means you say well, which one does the router and Sudan are aces in both they're worried.

P

K

So there was already a issue: that's brought up and when we added some of this registration of hey should we do see more.

K

P

K

My reaction to not having super in there currently just to kind of say what I'll say in the doc is I. Definitely don't want to have both and yeah I just present, whichever one they ask for like that seems unnecessarily complex.

K

Yes exactly so we agree that we should adopt in three, at least as far as I'm aware at this point, I don't see anything. That's particularly important. I would be driving IOT devices to need this, but yeah.

P

Or you could take an approach that says on some networks that might be constrained networks. They don't.

I

N

P

Devices, you might choose to sin, see we're only instead of JSON, so you're not doing both one of these low-power lanes or sometimes of this magic type and everything.

L

On there is when it's constrained devices do something.

P

So right now, I'm just pointing out that the document itself contains this interaction hell, even if it's stick to the current approach. Okay, thank.

J

You make sense, oh.

Q

Who didn't get I'm here to talk about.

Q

One thing that I did not get from the draft very well is.

I

Q

Coexistence of things that are not addresses being assigned mm-hmm.

I

Q

Still might affect other systems wearing. That's such as you know. Who are your results? Yes, so, as I understand it, please I very thrilled to be wrong about. If you have multiple pvd's, it seems like you might have multiple resolvers, some from dis or P DS, yes, and some of.

I

Q

May, in fact, be four have difference with DNS views. Yes and there's no information coming down that says in this case use this PVD because an application calling the operating system they have no idea what's gonna go ahead, am I correct so far,.

K

Can you clarify the last part about the application we'll have.

Q

Q

Possibly to concatenated lists of racers I think.

K

This is not yeah.

Q

It's discussed.

K

A bit in the draft but I think it's really relying a little bit more on the main npvd architecture. I think very specifically, you should not be concatenated arbitrarily right. So at least you know for our system. What imagine each PVD becoming like an interface like a separate interface right, and so the interface has a resolver when you do again at our info, at least for us.

K

If you are not specifying a specific interface that you are scoping information to you get the resolver for the default interface, and that's the only one you're going to be using then that if you explicitly select into another PVD, you use its resolver and its local address the application. The application must.

K

Gather info alone is not PVD aware; it doesn't also let you access the cellular link if you are on Wi-Fi network, so it is, it does not do this. There are API is both on Android iOS, other platforms that do let you specify the PVD that you want to be resolving into, and that's what this relies on.

Q

You are relying on yes, applications we're using these services like the NTP service, or this being.

K

Q

K

Q

K

So I'll there is a section on kind of the dns client handling will just make sure to indicate. I think what you want is the applications. Interaction to this.

N

That's great, thank you.

N

I'm, just gonna respond one of the things that.

R

Was in the process.

D

When mid-foot shut down was.

N

An API document.

I

So going faster, I was going to say, it'd, be really good to call the DNS thing and you've done. That I mean the thing. Is you your lack of timers and then you have get a delay and you must send a particular time yeah. Do you actually mean you must send up the time with like some resolution, or do you mean it must be late, yeah, yeah.

K

No be good to clarify because it may not be possible with the reality of the universe, yeah.

I

K

If we have that in the notes, I'll make sure to clarify that, thank you great. It's just nothing else. I think we will go on with our work of revising.

C

So for the security companies they.

K

C

K

From the the sector review, um we believe so there was some of it that wasn't entirely clear to us on exactly what they want to change. But, yes, we believe that is addressed.

L

Okay, Ron Bonica and I'm from Juniper Networks for about oh four years now, there's been work going on in the IETF to establish segments, routed traffic, engineered programmable tunnels, and there are two flavors of them: an MPLS flavored and an ipv6 flavored. Depending on what porting plane you use. This is a proposal for another kind of ipv6 flavored. This is the 101 level expose on SR v6, plus it's intended. So you can come into the spring working group tomorrow and understand what everybody's talking about, because there'll be a very abbreviated presentation there.

L

So what problem we solving.

L

L

Whoops, ignore that it didn't mean to put that there.

L

We want to implement a segment routing architecture we in one when code path, state in a packet as opposed to encoding path, state or it's storing path, state in a transit router. The way RSVP does we want to implement programmable paths and we'll talk about what a programmable path is late and we want to rely exclusively on ipv6 Philby, know MPLS anywheres in sight, and we want to leverage existing ipv6 features to the greatest degree possible, and we want to minimize overhead a couple of reasons we want to minimize overhead first sill path.

L

Encoding doesn't take many many bytes on the line. Second, so it's this Asics friendly. So to play the game, we need some terminology. The first is what's a path: it provides a unidirectional connectivity from an ingress node to an egress node. It can follow any path through the network least cost or a traffic engineered path. It contains one or more segments and we'll define segments later. It's programmable and we'll define what we mean by programmable later and a path is defined by the segments that it contains. Just like a line is defined by two points.

L

A path is defined by the segments it contains now. What's a segment well, a segment provides unidirectional connectivity from its ingress to egress. So we have paths that provide unidirectional connectivity in segments inside them. We'll see a picture of that in a minute. It's programmable and we'll describe that a little more in a slide. That's coming up. Its behavior is controlled by a topological instruction.

L

It's executed on the segment ingress node, it defines the segments egress node and it defines the method by which the ingress node forwards, packets to the egress node, a segment is defined by its ingress node and the topological instruction that controls it and a segment can be controlled by multiple paths, and there are exactly two types of segments strictly routed ones: they're similar to adjacency segments in SR MPLS.

L

They, the topological instruction that controls a strictly routed segment, Ford's a packet over a specified link to the egress, and then they were loosely route in one's the topological instruct instruction that controls a loosely routed segment, Ford's the path, a packet through the least-cost path to the egress node.

L

Now next thing we have is the concept of a segment identifier, a segment identifier identifies a segment. It identifies that sex section of the topology, because there's a one-to-one relationship between a segment and the topological instruction that controls it a segment. Identifier also identifies the topological instruction that controls the segment. Now a segment identifier identifies an instruction. It does not contain the instruction.

L

Therefore, an instruction might take many many many bits to ins code. A CID in SRV six-plus needs to be only 16 or 32 bits. Long SIDS are short. They also have node local significance, they're only processed by the ingress node. So some things too, to zero, went on a Sid identifies a segment. It identifies the topological instruction that controls a segment and it identifies the instruction. It does not contain the instruction. Therefore, it can be short now.

L

These are not the only instructions we said that segments are. Programmable. Paths are programmable. Yes, they have topological instructions used to steer from here to there their routing things. There were also service instructions, they augment a path, but don't define the path. A path can exist with one set of service instructions or a different set of service instructions, and we have two kinds of service instructions. One is per segment service instructions, they're executed on the segment egress node an example expose a packet to a specific firewall policy, expose a packet to a specific sampling policy.

L

You can see how these kinds of instructions might get used in service function. Chaining then, and these can be executed at the egress of any segment, the first second third or last, then we have per path service instructions. They can only be executed at the path egress node at the egress of the final segment. They always talk about D, encapsulating a packet and multiplexing the payload or D multiplexing, the payload. For instance. A service instruction might be D, encapsulate the packet and forwarded it across this specified link into this VP, M or D.

L

Encapsulate the packet lookup, the payload destination and this VPN routing table and forward it to the next. Stop that you find ok, the things we said about segments, this kind of is a picture to define it here. We have a path.

L

The path contains three segments, ACC D, D, D, F, a C and D, or ingress nodes, C, D and F our egress nodes, the topological instruction for AC, is executed on a the service instruction. If there is one for segment a is executed on C and the service instruction for the path, if there is one, is executed on F now, all this has been nicely theoretical. What does this have to do with ipv6?

L

Well, paths are encoded in ipv6 header chains.

L

Most everybody in this group knows what an ipv6 header chain is. There's a base, ipv6 header, there extension headers sr v6 relies on three of them in particular, but before we dive into that, let's talk a little bit about how headers headers are encoded. There's a recommended ordering hop-by-hop that are processed by every node destinations that precede routing they are processed by every segment. End point: there's a routing header, also processed by every segment, end point and a destination fragment, authentication, ESP and then a destination that is processed by the ultimate destination of the packet.

L

Now you can see from this ordering a very natural way to encode instructions.

L

Let's talk first about topological instructions, a very natural way to encode a topological instruction is in a routing header every well. Let's say we can probably know we have to go through the whole thing.

L

The routing header has a segment list and a number of segments left if segments left is equal to 0 you skip over it. If segments left is greater than 0. You decrement segments left over right, the destination address and forward to the destination address, so you can see how that's a natural place to put topological instructions.

L

Now, routing headers aren't used very widely in the internet and they're.

L

The one of the reasons is the size most routing headers that are defined today define every segment as an ipv6 address and they have 8 bytes of overhead. So let's say for a moment that you have a path with five segments five times. Sixteen bytes is 8088 bytes long and all of a sudden, you have 88 bytes of overhead in a world where the average packet might be 700 bytes long. It's not gonna work. Well, so we've come up with something called the compressed routing header.

L

The compressed routing header, just like any other routing header has a list of SIDS and a segments left in it. Each SID is either 16 or 32 bits long. um You have something called an S fib. It translates it's a data structure, it translates acid' to an ipv6 address and the install instructions that it represents. So as you're processing the routing header, you look at segments left decrement. It look at the CID lookup that said in in the S feb.

L

You now find the ipv6 address, that it represents copy it to the destination and forward according to the instruction, and that way you can get away with a really small routing header and here's what the routing header looks like when you have 16-bit encoding and when you have 32-bit encoding.

L

Now, let's talk about encoding service instructions, service instructions, we encode in a destination option setter and if it's a per segment service instruction, what we do is encode it in the destination option: header that comes before the routing header, that's processed at every segment, end point and what we actually put in there is a 32-bit identifier.

L

That's an identifier for the path. Every note every segment end point that is part of that path. That has a service in that path, knows that 32-bit identifier, when it sees it, it executes the service that it associates with that. 32-Bit identifier, we also have a per path service instruction. The per path service instruction is also a destination option- header, it's the destination option, header that comes just before the upper layer header at the end of the chain.

L

Again, it's a 32-bit entity and it's a 32-bit instruction that tells the node what to do d encapsulate the packet and forward. So what are the? What are the salient pieces of SR v6? First, that it is very specific about saying what pappa logical instruction what's a service instruction? Second, it puts topological instructions in a routing header. Topological instructions have to do with routing seems like a routing. Header is a good place to put them service instructions.

L

Well, some of them are processed at every segment, end point and we have destination options that precede the routing header that are processed exactly there. That's the right place to put them. We have service instructions that are processed only at the end of the path at the destination. Well, gee, that's why we call them destination options, so we put them there. The other salient piece is we'd, never try to encode an instruction in the segment identifier. The segment identifier identifies the segment. It identifies the instruction.

L

It does not contain the instruction, because of that, the segment identifier is short, and because of that, you can get away with a very short routing extension header. When you have a short extension header chain, it's a sick friendly and you don't have to do ugly things to keep your extension header chain short. The other nice thing about SR v6. Is it doesn't change the semantics of the ipv6 address you'll, see. The only thing we ever put in the ipv6 address field is an ipv6 address that identifies an interface.

L

The ipv6 address never contains an instruction that never contains anything else. Yes, it might. It might identify a loopback interface, but that's the biggest stretch. We make identifying a loopback interface as opposed to a physical interface or a a sub interface.

L

The drafts would like you to read, probably won't get time to read them all the first ones, the important one craft, Bonica, six-man, comp, I'm, sorry, the first ones, not the important one. Those are the other drafts. The draft would like you to read is that one craft Bonica spring SR, v6 + it'll, be presented in spring tomorrow and and in six-man the day after questions.

L

It's not clear yet whether they'll coexist, whether they'll merge, whether it's evolution all to be worked out tomorrow.

N

For my, is there a acid' distribution protocol? Yes,.

L

N

Isis and in fact well.

L

Actually, there are two of them if you are.

L

Its Isis, the OSPF one hasn't been written, yet those are the only two for SIDS, Isis and OSPF as for distributing service instructions per path. Well, we have a mechanism for doing that when the service instruction is encoded in MPLS, that's BGP, so we're going to reuse BGP.

L

In fact, it's one additional flag in BGP that says: don't encode this in an MPLS label, encoded in a destination option I.

L

Believe it's an IDR and it is let's see which one is that it is drafts on Glee IDR, VPN service, sr, v6 +.

C

So Vlad are you able to join the.

H

R

Well, hey I'm, going to give you a quick update on socks v6 so next time there are two major features that we're looking at fields are all now aligned and that the clients can have a proxy resolve addresses on their behalf and then relay the answers back to them. There are many more needs that have been made it into the dress, but we won't be getting into those too many to discuss so next slide.

R

I

R

Has always suffered in that regard because of variable field lengths, possibly the domain names are variable in size.

R

Now that the feature sets of feature set of socks is rather mature, we've set out to refactor the protocol, so the only victim of this refactoring was the minor version minor field, so it's now called sucks v6 rather than really 6.0. Otherwise, everything made it intact in one form or another, but they've all been shuffled around. Now all the figures in the draft.

R

For me to recall all the figures in this presentation so next slide, please so said the domain names were the major thorn in our side. Now we've decided to keep the usual format for domain, but we titled everything to the you know: it's multiple of four, it's rather straightforward. So here you see how the domain name for some site dot org is M, is encoded. We've got a length, let's bite, then the actual address, and then three bytes of padding our next type is so. Options also have undergone some refactoring.

R

So first up option kinds are now two bytes in size. Some option kinds used to have types and maybe response codes, but there weren't that many of them, so we've decided flat to threaten those. So at the example I am showing here in the slide is the option whereby a proxy tells the kind that an ID opponent token was accepted, so the kind used to be idempotence and then the type would you should be called expenditure I'd apply and the response code was called success.

R

So now in Chapter seven this was replaced with an empty option. That simply has a kind of either POTUS accepted now taxonomy is for auction still make sense for stock options or those haven't been modified, but these these flattened option types affect idempotence option in session and session options. So uh next slide please. So this the other major feature options whereby the proxy can resolve an address and relay the response back to the client. This is a non-standard feature currently available in source, so what we've basically done with it is that we legitimized it.

R

These options imitate that do address resolution, the semantics of get host by name of or get other info, not also DNS, so this kind of getting it any kind of TTL. So the basic assumption is that you perform at a resolution and that you're supposed to use the address in the immediate future Oh next type is so this. The way we do this is rather straightforward. Clients simply sends a resolution request as part of the Sox request.

R

If the client doesn't want I want to connect immediately to it to any host, it can do so. It can send the resolution request over no op. So its purpose of the proxy simply perform for address resolution and nothing else.

R

If the address in the request in the request was a domain name, the proxy, since, since back one option per supported layer, 3 address in this in this case, which it most like most like you, gonna- be an ipv4 option and I hope you before resolution option and an ipv6 resolution option if it cannot fit sports, resulting for example, ipv6, but it cannot resolve domain name to an ipv6 address. It simply sends back an empty option. The client knows that ipv6 resolution is on the table now.

R

If the address was a regular IP address than proxy performs reverse resolution and sends back a list of all the domain names next slide, please. So the first use case for this is UDP, so I have a placed sake. Header on the right. You can see that I've highlighted the address in red, so all packets, all UDP packets, that go through the proxy have to be prefixed with this header.

R

If the address is a rather long domain named and then we're, the client is going to have a lot less space to work with I mean further, if you're for the actual payload, it's roughly the equivalent of lowering the MTU. So it's far better to send an address resolution to ask forever for a just resolution over over TCP. Of course,.

H

R

Then the IP header is going to be a lot shorter.

R

R

So the other major use case is proxy flying ups by LD preload. Basically, we implement all the API calls that you want to be right, like connect your info or whatnot, and then a client that doesn't natively use Sox actually ends up using Sox.

R

Now in the network in the current networking API address resolution is done separately from the connect request, so clients don't know how to connect to a certain domain.

I

Without resolving.

R

It first so if we don't implement the replacement for get other info or get host by name, the application is simply going to have to perform its own DNS requests. Now. This is obviously bad if privacy's are concerned or if DNS is censored and also if you can lead to suboptimal use of CBN's. If the proxy has a significantly different vantage point.

R

So that's about it. For me, I, don't think stalks is you need of any more major features and.

S

Then Schwartz, google, it.

S

S

There's a growing number of applications that need more than address records out of the dns one, that's top of mind for a lot of people use encrypted SNI, and so it's true it's as it stands encrypted. Sni is essentially not compatible with common proxy protocols that exist today like including subs.

S

That is, if you want to do encrypted, sni through Sox. What you have to do as a client is form a DNS query packet yourself and deliver it as a generic UDP packet through the proxy with Sox. Why BBB to a DNS server of your choice and a crucial thing from my perspective- is that there is no way in this system for the client to direct it to a DNS server of the proxies choice. So the the application is actually forced to hard-code some set of DNS servers.

S

It cannot discover them through the proxy, so I'd like to consider that classic use cases you see.

R

But let's talk about it, I mean, if that's the major use case for Sox I am definitely willing to edit in the draft and imported.

M

O

Is like you know like there should be home. This work right and I was thinking like transpose, would be like a good home for it. Like generally for this and like I, didn't talk to the transfer. Ids and, like you know, Corey's right behind me. I think that it would be good thing that you actually present to them to the transfer folks, at least about this work and then we'll try to like figure out like well.

O

It's going to say because for me it's God like legs in multiple areas and I really think the transport is like the most relevant place to do this. But we can discuss that after, but he's presented all.

R

Right expect me to present it to the transport session at this ITF I could whip up some slides so.

I

Learn very fast him thinking of the florist is vwg.

I

We know to this drug at least existing in previous TS vwg meetings. I think it would be quite happy to have a couple of sites and really see if people have read. This is encouraging you to read it because before we do that, we can't really make a decision, but I think we should try this in transport and see if people who will buy it. People will read it and comment on it that.

R

Meeting I could probably whip up some slides.

R

Don't worry, okay,.

I

R

Write you an email, yeah.

I

And we will mention it on our agenda all right. Thank you.

K

Tell me call the Apple, so thank you again. If your presentations is it's a very interesting topic Thanks, so.

J

K

Comments, I definitely liked what Ben was saying about their needs for more DNS answers that the application may want to be able to get, and even within the a and quad-a answers you may have questions that are raised by.

F

K

What order are you giving those answers in? Are you actually waiting on the proxy side for both in quality responses? For example, you know we have guidance for how and client devices can do happy eyeballs and ideally things would not necessarily have to wait for both v4 and v6 in case, one is not coming back with an answer, so these are things that we could consider and if we were passing DNS messages all the way through the proxy. Maybe that would solve some of these issues.

R

So I, so my approach up until now was to create something that is simple enough and that covers the use cases that are currently in use by the to our team and yeah I mean I'm, definitely willing to modify it to include more features that the Modi and more DNS like features into this. If there's a need for them, I.

K

R

K

The motivation here is not just to add features, but it's taking into account things that really are good protections for the application like PSNI or performance optimizations like what we're doing with happy eyeballs that maybe weren't around or worth being considered in the original tour design, but do make sense when you take into account the current situation of things. The other point I had was regarding the UDP in your use case for needing to do the resolution in order to do UDP.

K

Don't to do that.

D

K

Perfect I mean you could have other schemes for getting that same effect, because, presumably when you are, if you do the lazy way of just sending the hostname every single time for every packet, the the proxy hopefully isn't doing a new resolution for each time right if it's random, remapping and so essentially you're just establishing.

I

K

Mapping, so you could kind of just do a similar thing of saying, I.

I

Want to start this UDP.

K

Flow, it's to this and I'm just going to use token one and just have a go very short field.

R

The thing is, UDP flows are not tied to a five couple.

R

Local bind address.

K

There are other things we can look at that don't did you separate out the issues of what we get back for rich DNS from the necessity, so we need to have efficient UDP practicing.

C

Thank you very much so Nix. This thing.

R

Thanks for having me thanks, leather.

C

P

Fullscreen, thank you.

P

All right so West ietf I present in an earlier version of this and the issues that had been brought up before that time and since then new issues have been brought up, and so it's been a grab to address those in 204. This document is being a tea sponsored by Suresh and reviewed by this group and others.

P

It was a one at the time that I presented it in an IETF 104. There's four issues: I've started using github to track them. Those are the four issues. I've got a slide on each of those and I'm going to cover them, not in numerical order, but in order of biggest Moore's general down to the list, most specific, ok, all right, here's the biggest one, ok, this came up and lots of discussion are on the software if' tunnel document that was doing the yang module for if' types.

P

Ok, and so there was a bunch of people and a bunch of confusion about. Oh, this is defining a new registry right shouldn't you be adding new values when defining a new registry right. The resolution of that discussion is no. In fact, it's not defining a new registry, it's defining a new format for the same registry right. You can't have different values in the yang module then appear in either the mid module or the registry. That least lists them in a table. Ok, it's really an alternate format of the same registry.

P

Ok and so this was updated, or this was addressed in draft Oh 3 by clarifying that they're just alternate formats in the same way as you can get registries, some registries in XML or HTML or CSV- and this is just potentially two more options- you could get stuff in yang format or mid format, but it's exactly the same values just like the values are the same, depending on whether you get it in HTML or XML or CSV format.

P

It's the same registry right, so this tried to express that it was a new section that was added for this discussion right, because this wasn't discussed in the draft before ok. This also talks about recommendations to Ayane as to how to address this confusion in the website, without being prescriptive about UI or whatever I just concepts.

P

Okay, and so the gist of it, is that it proposes to present the mid and yang modules for if' types and we'll see tunnel types, which is the other issues as if they were available formats, not quote unquote, registries, so an example of what I'm talking about. If you look on the left side, this is example of a page that has multiple available formats. You see XML, HTML and plain text.

P

This is actually on the same page as the one that's on the right is just way up at the top as the same there's one page, that's multiple registration site. The point is, you have some descriptive text. It talks about how you register a value and you have some tables. You have links to alternate formats when you look at the if' type one today, you can see. There's this little note that says for everything, that's in the table right.

P

It needs to be updated in the if' type nib and in the if' type yang module, which are separate pages okay separately down here you see available formats. Okay, so you can see how a reader would say. These are available formats. These are other registries that FB kept consistent. Hence the confusion right. So the proposal is for I, Anna and I was chatting with Ayane early this week.

P

I don't know if Michelle came into the room, yet she was going to try to be here for this, but this type of discussion here should ideally be represented as if they were available formats, which is more reflecting reality of how the allocation happens. Right and so Ayanna's has to do various tooling issues and is doing tooling issues anyway, as they're rewriting their system to say hey. Can you somehow incorporate this?

P

You can imagine down here in the ideal world, you'd see CSV mid and yang, okay and you click on them and you get exactly the same values and all three of them they're just available formats right.

P

So this is, if you have a hard time figure out what I'm talking about this is trying to make it be real as an example right and, of course, the look and feel this website may change over time right, and so the document doesn't talk about that and just says available formats, which is Lanna concept as opposed to registry, which is not and a concept okay. So that was the biggest change and, as a result, this one the the document, the software if' tunnel document- is now in the RFC. Editor queue right.

P

This discussion helped to resolve that as well. Okay, next issue, the tunnel type was mentioned in this document and I talked about it a little bit at last IETF, but there was certainly not equal coverage write. The document talked about if' types right in the registration for if' types, but the tunnel type registry is on the same page. It must always have the same designated experts. It must always have the same assignment policy by RFC.

P

That's the requirement in the actual RFC is that must be the same okay and so part of the expert review, because it has the same experts myself and Dan Ramos Connor, the same experts, part of our job when a request comes in, is to verify they're asking for the right thing right, they're asking for a tunnel type and we could come back and say no, no, you really mean a tunnel tire, an if' type or vice-versa right. That's part of the review that we do just making sure that they're asking for the right one right.

P

What's the same experts for both of them, one is a subtype of the other okay, and so we said well, given that pretty much almost all the considerations, the same other than a couple of language terminology, we said it would make sense to expand the document to add in and tunnel type in their various places. Okay, so we did that Hey and so, as a result, the title change to have an tunnel types in the title: hey the title.

P

You should just say guidelines and registration procedures for interface types, and now it's and tunnel types, and now the treatment is equal. Well, that was the intent, but we missed 103, and so this one is saying: OOP we missed a spot, and so we needed to Rev. Oh four, we missed a spot, which is this one.

P

If you look at how you ask for a value hey last time, I talked about how you can either ask for a value by filling out a form by going to an ax site and clicking on an assignment and clicking a thing, there's a specific form for if' types or you can just send them. Email and they'll. Accept it either way right. But if you look for tunnel types, there's no form.

P

Okay, you just have to send email and there's not actually any place in any document that says, here's the template, you must use to fill out the picture. You know the the fields you have to fill out, even when sending email and so as a result, for example the iaf type. Even the old RFC write.

P

This sentence appears in the current one, which was copied from the older version on the Internet interfaces made by the one before that this template describes the fields that must be supplied in a registration request suitable for adding that f-type registry. Okay. So that means as designated experts. We don't accept ones that aren't missing those fields. We send it back saying: please follow the most and send it back to us. Okay, we can't apply that policy to tunnel types right, because tunnel types have no must saying: here's the field.

P

You have to send us so there's kind of conflicted with this argument that says same assignment policy, but by the way we can't apply the same thing, because this must is missing right and so we said sure unless you specify a template because they're required. The questions are the same question. So, let's just say that right, okay, and so now, if I Anna wants to have a forum, they could do that. The document doesn't comment on whether they should have a forum or not.

P

But now it's free to you because there's a specific set of fields that this is proposing but happen to match the same set of fields as you'd, specify for an if' type, okay other than they say tunnel instead of interface.

P

Okay for the last issue, I'm gonna put this slide up. This slide, I showed it last IETF. Okay, last ITF I explained that there's subtypes, like I F type 131, has different subtypes of different types of tunnels. You know GRE and tirado and all the different things attack on a soft wire, and so us it's a subtype relationship between I have types and some types.

P

There are things that are alternate value relationships and last I, ATF I explained that here's, the I F type for Ethernet and then once upon a time there was all these other values that were then later deprecated saying you know really shouldn't define new values just because the maximum bandwidth changed right. You should just use this once these were deprecated right, but the point is there are cases that use alternate values for similar technologies. Another cases were sub layers right where there's a D multiplexing relationship or what have you?

P

That means that it shows up twice in the stack from top to bottom or IP or whatever is at the top, and the physical network is at the bottom of the stack. Okay, there's a three relationship: subtype alternate values in sub layer, okay, so the last issue was subtypes and sub layers had discussion in the document.

P

Alternate values had none, and so there was a comment from who said in Suresh posted the mail out to says: hey any feedback on adopting this or me ad sponsoring at right and one of meds comments. One was covered by a previous when I already covered- and this is his other one- add some text to encourage udp-based tunnel protocol designers to register their own code instead of reusing the one currently assigned to the JIRA qdp and cap okay.

P

So it's actually touching on that alternate value thing right, because in one case back here we said the IETF said you should not be using alternate value, should kind of reuse the same one right and in the UDP tunnel case. This is a case where we actually want them to be different, and so what's the principle behind that? That's what this issue is filing.

P

What's the principle behind that and dan and I said well, there actually is an important principle behind here: okay, which I'll show in the next slide the text that we added, because both of these decisions are correct and we'll say why okay, and so we added the section called alternate values that says talks about guidance for when you should consider using an alternate value and when you should try to either use an existing one, okay and so on the UDP issue that med mentioned the UDP value by the way.

P

One of the reasons that it's problematic as the UDP value was originally added for this RFC one, two three for encapsulation, okay, RFC one, two three four is a way of doing encapsulation over UDP that can also encapsulate multicast packets, okay, over a multicast distribution network right many other UDP, encapsulation protocols, tirado and so on, cannot do that. Okay, and so this notion that says well, this particular UDP one doesn't really work the other ones, because the expectations are wrong. Okay- and that gets to the core of this- it says.

P

Okay, we can generalize this problem, okay, and so in this case, when traído and these other udp-based ones got their own value. There was a good reason for that and that's what led us to this text. Okay after we discussed these two examples. We said these are both examples of correct ones, and so we, since they came to opposite conclusions, we talked about both examples in the document as guidance right so from this quote. Down to this quote is the actual text in the document right now and I tried to format it.

P

Just you can highlight and see, says: okay, there's two cases here: okay, you use a new one, whether it's AI, f-type or tunnel type use a new one whenever key aspects, such as a header format of the link model, okay, are significantly different right. So in the trade over says one two, three four versus various other softwares one, the link model is significantly different, and so therefore you should ask for a new value right. You shouldn't try to reuse UDP, you shouldn't try to reuse, Ethernet or whatever create a new value.

P

If it's a new link model or header format, okay, but reuse, the same value like in the multiple copies of Ethernet example, if the differences can be expressed in differing values of existing objects, like link bandwidth right, this is a separate object.

P

You don't need the if' type to figure that out right, and so in the Ethernet case, the only differences were ones that could be expressed at other objects already within other things in the same table: okay, so in Ethernet one this applied and in the UDP tunnel case this one applied- and this gives a more generalized guidance that is hopefully reusable in future I.

P

O

Really good that you, like you, know somebody file, like you know the difference between them. So I am really happy that you did it. Okay,.

P

Great, thank you, okay, so all of the issues that are addressed in those ones are ones that were raised since last IETF, based on the two calls right, though, the IETF last call on the software is document, and then Suresh is call 480 sponsoring this one. All of these, we believe, have been addressed to people satisfaction, so we don't believe that there are new issues- okay and so I'm just reporting that out, but we think that our job is done until any new issues are raised and we invite the community to raise any new ones.

O

So something else right so.

P

I see Michelle came in, is there anything else you wanted to add. I did mention that the tooling issues Ayane was investigating in the future, and so exactly how things would affect a website was something Ayane would decide. I just mentioned here's the principles from the community for Anna to take into account yes thumbs up. Okay. For me, deco. That was just a thumbs up from from Michelle on behalf of Anna.

I

Is there anything that transport area needs to help with this? No, don't think so. Shall we just mention these going to last call the.

P

Only other write them that there is an area that we want to get specific review from, which may or may not affect this document, which is ops area right, because this.

P

This first issue here comes up whenever you have a case where you want a mid and a yang module to be defined as having always always always the same values, and they must never differ so allocation of a value affects both of them right. In theory, this might actually be a precedent for other cases beyond if' type and Tunnel type. I am not the designated expert for any other ones. Okay, so I am setting a precedent here that the ops area ad or whatever could choose to use in other cases.

P

Here, that's not what this document is doing, but the IETF could choose to do that.

G

He said that transport.

P

Area and ops peer review would be welcome right. That's my co-author, saying that. Thank you.

B

You know I, don't know, timing.

B

Resources, so I would be a little concerned with, of course, you know you go to IETF s. Call everything this looks it gets approved, might be sitting to her a little while now the whole entire thing to do. There is, if there's something in the I Ana consideration section that says and I'll try to find the document do something similar basically says that you're going to work out the tooling the publication of the document doesn't meet week for that.

B

So, if I can find what I'm thinking of I'll send it to you and review, the working group wants to consider that. So you don't have to wait on publication for us to do what we gotta do right.

P

We consider this just requirements for the registry. The actual implementation will lag the requirements, obviously so yeah.