Detecting Network Attachment BOF (dna)

These are the minutes for second the Detecting Network Attachement BOF (dna) meeting, held at IETF-58 on Tuesday, November 11, 2003, at Minneapolis Hilton. Thanks to Ted Lemon for the notes on which these minutes are based on. These minutes were compiled by Pekka Nikander.

Session Chairs: Greg Daley and Pekka Nikander.

Decisions

  1. Get Charter worked out and to ADs
  2. Determine location for DAD Optimization work quickly
  3. Determine appropriate mechanism for liaison with link standards organizations (DNA, IETF or Individuals)
  4. Write a catalogue of existing Link Hints for DNA

Summary of discussions

There are several discussion areas within the Session: DNA for IPv4, DNA for IPv6, IPv6 DAD optimization and Link Hinting. Not all of these will be in a potential DNA working group. Discussion in the session was largely about which components should compose a Working Group, and what parts are out-of-scope.

There seems to be enough interest to form a WG, but it's not clear whether IPv6 DAD optimization should be in DNA or IPv6. This is largely a decision about where the documents would best be supported and reviewed.

Link Hints are useful to IPv4 and IPv6 link change detection. There are a variety of hints available today, which it seems valuable to catalogue for DNA implementors. Variation in link hints, and ambiguity of information from Link-layers make change detection difficult. It's unlikely that we (in the IETF) can have an impact on these issues, except through discussion with link developers. Delving deeply into link layer issues may therefore be counter-productive to a DNA WG.

Points to pay attention to

Presentations and Discussion

Introduction

Greg Daley gave status reports for proposed charter items for detecting network attachment.

Greg Daley:

It looks like DNAv4 is going to be taken care by the DHC working group. However, there will be an update, presented by Bernard Aboba, of how the work is going.

The DNAv6 problem statement is coming up, but not yet in the repository. JinHyeock Choi will give a presentation. IPv6 DAD Optimization Goals and Requirements is out in the repository, and will be presented by Daniel Park.

There are two presentations about link layer hints:

  • Parameters for L2 Hints by Nicola Montavont, and
  • Link Layer hints for DNA by Alper Yegin
    • .

We'll have the discussion of these two together.

DNA for IPv6 problem statement

JinHyoeck Choi gave a presentation about the DNA for IPv6 problem statement, discussing some of the work that they are doing locally (testbed to evaluate movement detection), the problems caused when L2 links do not match with L3 links, and in general the problem how the current ND procedure is not fast enough for some applications.

He suggested an approach where a link layer hint causes a detection procedure to be activated, possibly leading to acquiring new routing prefixes. The explicit problems in the current environment are the following:

JunHyoeck concluded his presentation by giving a number of "requirements":

Bernard Aboba:
Why use network unreachability, why not send RA message immediately? We do this in v4 because we don't have RS/RA.
JinHyoeck Choi:
If you have two routers, this could cause problems if the wrong one answers first.
Greg Daley:
Answer: this was defined as the reachability test in RFC2461. This is also mentioned in MIPv6. Basically, these are trying to avoid expensive reachability checks.
Vijay Depravapalli:
What is the reason for that? Think about what happens if you have 50 users on an access point which goes down and comes back. There have been extensive discussions on this. We need to first check whether the node is on a new link, and only then do RS/RA.

DNA in IPv4 presentation

Bernard Aboba gave an overview of what is happening with DNA for IPv4. Basically, DNA for IPv4 is a WG issue at the DHC WG. There is an issue list available at http://www.drizzle.com/~aboba/DNA/dnaissues.html.

Issue 7, ARP contents, requires some more attention. There you send an ARP request with your likely address. However, this doesn't work in private networks, where you need to use the unspecified address.

Thomas Narten:
What are the implications of this to other documents?
Bernard Aboba:
You can't poison the ARP cache.

Issue 10, strong vs. weaks hints, is also important. This deals with behaviour, i.e., you may want to have reachability test anyway.

As his final thoughts, Bernard considered what really is a hint, and came to a conclusion that a hint can be wrong. Hence, the mechanism adopted must be robust against misleading hints, and some kind of verificaiton is always needed. Considering the differences between v4 and v6 DNA, in v4 you ARP for the primary router and check the MAC address, in v6 you have to deal with the problem of alternate routers.

Ted Lemon:
What about hysteresis?
Greg Daley:
We should talk about this on the mailing list.
Ted Lemon:
Why not use a well-known address as source address? You never need to use that address even if it would posison your ARP cache? Allocate one address; must not be IPv4 link local address.
Thomas Narten:
This could be used all the time, even in public network case.
Bernard Aboba:
Unless you have a private network, nothing bad happens.
Greg Daley:
Not convinced that's useful in all cases. Could use one of the reserved IPv4ll addresses. But since you need to put some extra code intot the stack anyway, this may be worth considering.
Ted Lemon:
In a wireless situation, you detect a loss of contact and a new strong beacon, you need to throw away all IP stuff, and then you may detect two routers advertising different prefixes. Hence, it would be good to have something about how quickly you jump to conclusions: in what circumstances to jump to conclucsion or when to wait. For example, what to do with the rogue address points here at the IETF meeting advertising the IETF58 SSID.
Bernard Aboba:
One could place the network info in a cache, indexed by the default gateway's IP address and MAC address. if your ESSID changes, you most likely change your network. So, you should go out and discover a new address, but you are not invalidating your lease, yet.
Ted Lemon:
The issue is about configuring your stack, not about DHC lease. Everything upper in the stack is gone.

Greg Daley cut the discussion; it should be continued at the list.

DAD optimization goals and requirements

Daniel Soohong Park gave a presentation about DAD optimization goals and requirements, discussing in which working group the work should be done, giving some history (the work was discussed many times in mobile ip, then in ipv6 and the previous DNA bof), reminded that the first DNA bof decided that DAD optimization would be an item on its list.

There are curently three basic approaches to solving the problem

The actual requirements are available on two slides in the presentation.

Parameters for Link hints

Nicolas Montavont gave a presentation of what should be included in link hints.

Link-layer hints for DNA

Alper Yegin gave a presentation about link-layer hints for DNA, discussing how link layers can assist DNA algorithms, what are the differences between GPRS, CDMA2000, and 802.11, and how one can create abstraction based on these. He came to the conclusion that there are two different concepts, triggers and hints.

James Kempf:
Bernard made the point that hints need to be verified.

In GPRS and CDMA2k, my understanding is that if you get information in those networks it doesn't have to be verified, because the network controls where you are going, and if it tells you something, it's not wrong.

802.11 is very different. Very little indication of how to map to the IP layer, it's very complicated. I think movement detection is a kind of a misnomer because you're really moving at layer two, and your routing's changing or not at layer three. So you're trying to detect routing change, or need to take action to change routing (mobile IP). So in first two cases you can use info in these triggers to reliably determine whether you need to change your routing. In last case you need to probe, etc.

Unknown Speaker 1:
Trigger just says your link has changed, layer up has to determine what to do next.
Unknown Speaker 2:
In CDMA2k, the PPP link going down/up is reliable indication you have to do something.
Bernard Aboba:
I think there's a distinction between indication that something's changed, which might be reliable, and indication that you have meaningful layer three connectivity. You get an IP address, but you don't have reachability. Helpful for multihoming case.
Unknown Speaker 2:
There might be two ppp links of interest, one between laptop and phone, other between phone and network. Hence, you need to be careful.
Greg Daley:
There's a distinction between routing function and ppp function.

BOF status discussion

Greg Daley:
We have a bof which has a fairly diverse set of goals. Looks like DNAv4 stays in DHC. Can DNAv6 be a goal in itself? Does DAD optimization belong here? I think there's interest enough in link hints to do a catalog. I don't think there's a lot of reason to go deep into abstractions. We might just be doing the wrong thing.
James Kempf:
I think one of the problems with this whole topic area is that IETF can't solve the problem. Problem is in 802.11, which doesn't give host enough information.

I think the problem is that if we start a WG and from the get-go it's apparent that the most difficult part of the problem is something that we can't solve, it's kind of setting ourselves up for frustration.

So it's important to know what part we can't solve, and not try to solve it, but to instead focus on the part we can solve.

Thomas Narten:
Agree with James to some degree. This business of link hints is potentially useful to catalog and describe so people understand it, but ultimately the stuff that goes on in L2 we don't have much influence over. We can determine if we are on the same IP link as before. If we can make improvements there, we've done something positive.
Basaravaj Patil:
The link hints problem there are other parts of IETF can benefit. Agree it's hard to solve. If you take fast handoff work, I think that the link hints is a very critical piece of the solution, particularly handoffs across different types of technology. Would be good if IETF takes an approach. Depends on how you scope the problem - create an abstraction that doesn't depend specifically on IEEE stuff. Work is very useful, we have been discussing link hints for a couple of years now.
Bernard Aboba:
Part of the reason nothing's come out of it, you have to look very closely at the application. For TCP it might mean something very different than for DNA.

In particular, some of the discussions Greg has been having, what are you proving? I think it's relevant. It doesn't take an enormous amount of effort to answer the question of what to do with each hint. RAID or signal strength.

Thomas Narten:
One thing I do get a little nervous about is when people say L2 triggers or hints are critical to making this stuff work. There we run a risk of getting on a side track.
Basaravaj Patil:
Proprietary mechanisms of detecting triggers can be and has been developed. The whole point of standardization is interoperability. The Question is, can we have a standard way of doing it, and make real time applications work better?
Greg Daley:
Quite possibly correct--we're the puny weaklings. But talking to IEEE and knowing what we want does help.
Basaravaj Patil:
Is there a problem in talking to IEEE?
Greg Daley:
I think we can do it. Whether DNA is right group I don't know.
Thomas Narten:
Wary of IETF trying to come up with consensus on what to tell IEEE in this space. Easiest way to make progress is to just go over there and make the arguments.
[Greg Daley:
Can we leave comments to those who are standing up behind the microphone?]
Brajesh Kumar:
802.11 could use for any technology. PPP establishment is a fairly strong hint. So even if perhaps we get no strong hint from 802.11 now. If we can articulate the problem there maybe we can be more useful in that context. We should not be scared of any of the problems just because we have no mechanisms from link layer yet to resolve them.
James Kempf:
Bernard and I are working on stuff with IEEE. Situation is that right now as you have described it's pretty bad with 802.11. 802.16 nobody's looked at. 802.20 is coming. Whole list of possible protocols that might need some work.

Obviously IETF is not going to get into that. Somehow we have to figure out some way that they can get their process to deal with it.

We did this quite successfully with 3gpp. Would like to do something similar with this.

Bernard Aboba:
There's ways to go about this. Instances where IETF has been able to give guidance. Pilc - advice for link designers. If someone were designing a link in the future, might help. Having been in sessions, not sure the help we'll provide will be worse than the disease.

They're looking at a whole bunch of things including changing the IETF's use of triggers. Important to tease out fundamental principles, don't need to characterize everything.

IPv6 DAD optimization

Greg Daley:
Opinion on where IPv6 DAD should be done?
Thomas Narten:
I have opinions, but at some level either group could do work, it's a management decision where it's got best chance of success. The high level bit is that this problem needs to be solved, we need to give it a home.
Greg Daley:
Ask room?
Pekka Nikander:
I guess if we are going to ask room opinion we need more background.
Thomas Narten:
Then we should just go on, maybe - might take too long.
Greg Daley:
Idea was that there were at least two drafts which would be pushed forward at this time try and get some idea of the goals or requirements and get a candidate DAD optimization spec. Any additional stuff if there's different properties we can have a look at those.

At least get something to go towards standards track. People are screaming for it.

Thomas Narten:
My assumption is make sure we have a clear problem statement, and we develop a solution in the standards track.
Pekka Nikander:
Here's a brief summary. I think there are two major issues. One is IETF ask for working group, we really should focus on IP layer. We should not go too far to link-layer issues. Second thing, there is pretty strong interest in these link-layer issues, definitely a need for some kind of liason to IEEE.

Whether it's a WG job or belongs to some other part of IETF needs to be clarified. If we are progressing towards WG, safer way is to focus on IP layer issues.

But both should be addressed in some way.

Unknown speaker 3:
Might be useful for wg to catalog what hints might be useful, give it to whoever goes to IEEE.

One thing on link layer hints, no other group looking at this issue. Main user of those hints will be the DNA group, I think those drafts are very useful. We have to not only catalog all those hints, but what use they are.

Alper Yegin:
Two parts - identify what is out there, how we use it in DNA. Second, what else could be helpful? Falls beyond the boundaries of IETF. If we are not going to do the first part, are we going to completely ignore what we can get out of link layer? Purely network layer?
Greg Daley:
I think there's ways of dividing this sort of work in network layer.
Erik Nugugu:
I think that even if you cannot change what is being standards, you can leave implementors some guidelines on how to implement interaction between link two and link three. I think the point is not about trying to change what we are doing, but trying to abstract some guidelines.
Greg Daley:
We've got to wrap this up. Please get on list, say if you want it a WG. Input in charter needed, or you will get a bad WG or no WG.

Valid XHTML 1.0!

Copyright  ©  2003 Internet Engineering Task Force.