[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[DNA-BOF] IETF 57 Session Minutes
DNA BoF - 2003/07/18 - notes by Brett Pentland and TJ Kniveton
Minutes.
Introduction Greg Daley (GD)
GD:
slides are online http://www.ctie.monash.edu.au/dna/
GD: Detecting Network Attachment - mechanism by which hosts can determine
whether they're attached to networks through existing means.
Applicable to intermittent connectivity, etc. so you can
determine whether address configurations are valid.
This is important for upper level sessions with time
constraints, or are sensitive to packet loss.
Concentrates on how can we reliably detect attachment.
Upper layer protocols -
IP mobility services,
DHCP configuration,
DAD,
protos like TCP, ..
Determine whether these mechanisms are available for
v4 and also v6.
We have some ideas already, is BOF interested in this?
Existing previous work in mobile ipv6, zeroconf, dhc,
We'll cover this first with a couple of presentations
Movement Detection in Mobile IPv6 - JinHyeock Choi (JC)
JC:
Table of Contents:
* MD overview
* process
* methods
* problems, req & further steps
Movement Detection Overview:
----------------------------
As an example:
MN is attached to AP1, which is in front of AR1.
Then it connects to AP2, connected to AR2.
The MN receives some hint that it might have moved..
Then it checks whether it can still reach AR1 using NS...
Movement Detection Process:
---------------------------
step 1 - Hint,
step 2 - Check reachability of current AR.
step 3 - Check validity of current CoA.
step 4 - Router discovery with all necessary information.
A Hint may be an L2 trigger, new RA msg, RA beaconing.
Check reachability of current AR uses either:
NUD (3 NS probes)
one NS and timeout
or
RA beaconing
Checking validity of current CoA.
undertake RS/RA exchange, check whether prefix
of current CoA is in RA.
Router Discovery with necessary information - RS/RA exchange.
Movement Detection Problems:
----------------------------
Inconsistency of RA information (link-local scope of rtr addr,
prefix may be omitted).
Delay to check reachability of current CoA.
Random delay in RS/RA exchange.
Erroneous Detection/Unnecessary Signalling
May be caused by Eager Cell Switching (ECS)
without L2 support
Movement Detection Scheme Requirements.
Fast: Low Time Delay
Precise/Secure: Little Error
Efficient: Limit Signaling (NS/NA or RS/RA)
Further Steps
-------------
Basic MD scheme as guideline for MIPv6
Optimized MD scheme for faster handovers.
TJ Kniveton (TJ): You talked about a lot of different
upper layer protos and applications.
What are the parameters for supporting
movement detection when low latency is
a goal versus general.
GD: We're looking at the situation where movement prediction
hasn't happened: This is the basic operating support when
fast handoff is not available.
Looking at solutions we'd be able to deploy in
next yr or so that can provide operational
support for people trying to determine these
things within 30-40 ms
JC:
I've talked to implementors and they don't have a clear
way to detect movement. Required at least for MIPv6,
but we don't want to require FMIPv6.
GD: There is a general requirement for this in MIPv6, and
it's good to have one set of messages over the link
which we can rely upon for network attachment detection.
TJ:
There are general ways of Movement Detection, and lots
of Link Layers with different capabilities. Are we
aiming at Layer 3 or specific Link Layers?
GD:
Principally at L3, but might be supported by particular
types of enhancements by using ll triggers. If we get a
strong hint form 802.11, SSID changed, for instance.
We're not going to standardize stuff in L2, but maybe
provide general guidelines for people using L2 with
these capabilities.
JH:
It is difficult to support fast movement detection
without L2 triggers. But some link layer technologies are
more friendly to movement detection. So some solutions
only work with certain L2s
GD: There's some work on including L3 information in L2
Messages,
but we don't want to re-implement for each L2.
Presentation by Bernard Aboba (BA):
DNA in IPv4.
Use/misuse of IPv4 LL addrs.
Today's hosts are often mobile. May or may not use Mobile-ip.
IPv4 address LinkLocal addr usage in v4 is usually a *mistake*.
How do we make address assignment more resilient and hopefully faster?
Hints are non-definitive indications. A host has to test them.
L2:
* 802.11 SSID
* ifra/adhoc
* IEEE 802 LLDP traffic
L3:
* IRDP.
We define a "most likely" point of attachment (POA).
This is a best guess, based on hints. By default this
is the previous POA.
Reachability detection: ARP request sent to most likely default
gateway. If most likely POA was autoconf network, then ARP request
is sent to an autoconf neighbor. Also, you have to test MAC address
as well. This is kind of tricky, because network might now be
configured instead of zeroconf.
As a strawman proposal, we formulate most likely POA. Is IPv4 LL
ever "most likely"? Maybe if previous POA was autoconf.
With DHCP, Check for valid ip addr lease (<t1). If this is valid,
perform reachability detection on default gateway of most likely.
If this succeeds, reuse the address. Otherwise, send a DHCP Request
in INIT-REBOOT state.
If there is no valid IP address lease, or no response to DHCP Request
after retransmission, go to INIT state.
Empirical evidence is that this is invalid much of the time
(you just end up disconnecting yourself from the network for about
5 minutes), but it could be required. If IPv4LL is allocated, how
often do we attempt to obtain a routable IP address?
What RFC2131 says..
Sec 2.2 server and client probing.
Sec 3.1 Retransmission of DHCP Request:
60s Max (is kind of long for mobility).
Sec 3.2 If you don't get an answer to dhcp req.
you may choose to use previously allocated network address
anyway.
Sec 3.7 Reacquisition. "should use DHCP to reacquire after
disconnection from local network".
-- Probably want to run on link-up, not link-down.
You might have multiple different addresses that you can continue
to use.
draft-ietf-zeroconf-ipv4-linklocal-08 probing isn't always mandatory,
Why DHCP shouldn't alloc LL addrs.
Someone else could have acquired your address while you were asleep.
you wake up, and now you have a conflict. So you have to claim and
defend. But you may have woken up on a different network than before.
but you may now be on a routable network instead of zeroconf.
So you may roam around and never actually be connected.
Solution - don't select an IPv4LL as a first resort. Test
reachability of autoconf neighbor(s) first. But you could be all
wrong!
Summary: There are multiple ways you could have mobile hosts that
are never connected.. i.e. 802.1x + premature DHCP + LLv4 +
5 minute timeout, Naive IPv4LL implementation.
Where should this work be handled?
Ralph Droms (RD): Thank you for taking on this work. Clearly we
tried to capture this in rfc2131, and sort of got it right.
We got disconnected vs connected incorrect in DHCP, and it
will be corrected. Your document really does span two
separate pieces of work. Also it spans 2-3 WGs. We could
take the document as is for the intersection of WGs, or
break it into pieces:
* Here are the hints
* Here are the things which need fixing
in DHCPv4/LLv4 etc.
I wonder which way we move forward on this.
Spencer Dawkins(SD): On heuristics of figuring out where you are ..
conversations about similar thing in different context - In
Trigtran, we discussed instability of certain triggers.
For example, in 802.11, we're not sure if the link is
actually up or down. Is this covered?
BA:
Yes, there is a danger from spurious triggers. There has to
be some damping. It's a 2-edged sword, because when you do
it, it makes it slower. We don't know correct damping
constant to satisfy everyone.
We have seen situations where hosts have received 10 up/down
indications per second.
This would be something we would talk about:
What do you do with a link-up in the last 0.10 second?
But someone will probably come up with some supersonic flight
situation where you need it..
Thomas Narten (TN): It may be useful to break these into several
documents. We don't want to hide all of this
information inside bigger documents where the implementors
won't see it. Some of the stuff the mobility community is
doing is general purpose not just to do with mobility.
It's just fast detection of link-up at lower levels.
I'd like to see this all in one place, but in a location
where mobility is just one customer of the information.
BA:
Interplay between these things that might not be appreciated
in individual documents.
Rob Austein (RA): (Without IAB hat, w/operations hat).n We see this. In
Atlanta on the IETF network, it's a real operations nightmare.
BA:
By the way this is not always LinkLocal.
RA:
Card drivers, Pulling laptops out of suspend, etc. usually
end up with tech support claims. It sounds like this work
needs to be heavily focused on getting LL fixed. Do we
do this in the zeroconf WG? or they need it as input at least.
TN:
(AD hat off). I think there's agreement that the zeroconf
document needs to be clear about using it as a last resort
instead of leaving it neutral. We need to bring it up in
zeroconf to clean it up in that document.
RD:
We may need to feed this into zeroconf. More strongly,
we also need to adress interaction between what zeroconf
is writing down that affects operation of DHCP hosts with
RFC 2131.
BA:
We have to send this issue to zeroconf WG mailing list.
Itojun(I):
Assuming that zeroconf and DHCP are fixed, what
kind of document would be created, standards
track or informational? I prefer informational better.
BA:
It shouldn't change protocols in any way, so informational
might be better.
TN:
Need a document which says here's a bunch of issues, and
provides guidelines. We need to get more experience with it.
We know how to deal with 80% of cases, but edge cases...
BA: Well we know, but this is not necessarily reflected in
implementations that are out there.
Presentation by Ralph Droms
(Some Slides by GD)
Following up on bernard's work, I want to say what's done
regarding movement detectin in DHCPv6.
Section 18.1.2 if client moved to new link, prefix no longer
valid, go back to server to find out if on same link (same as v4).
Lists times at which client may have moved, 4 examples - Reboot,
Physically Disconnected, Return from Sleep, Wireless change of AP's.
It's pretty handwavey.
We leave it to the implementor to figure out how to accomodate
a wide variety of tech's.
Send dhcpv6 confirm message that goes to any available server,
servers compare link on which received to server's model of network
architecture on server side. If the prefixes in the confirm message
are appropriate for the link, it sends back a response with
completion code of success. If any addresses are not appropriate,
send back Not-on-Link reply. In this case, the client knows it
needs to go back to DHCP server to get addresses appropriate
to the currently attached link.
Retransmission and timeouts - Initial random delay between 0 and 1
second. Retransmit delay of client, max of 10s, and randomized
exponential backoff.
The maximum number of retries? don't remember (GD: none, just
maximum duration)
Client may use previous addresses if it doesn't get response.
The Router Advertisement might not entail you have DHCP unless
the M bit is set. Need to know you have server available.
Difference between DHCPv6 and DHCPv4:
* Use of DHCP can be controlled by RAs in IPv6.
* Hosts can avoid latency in determining there is no
DHCPv6 ( M bit = 0 )on a particular link.
In IPv6 there's no dichotomy betw LinkLocal addresses and
assigned routable addresses. In v4, we have to pick one or the other.
BA: You only get a timeout if you're:
* unable to confirm reachability
* RS/RA tells you you're using DHCPv6
* You're not getting any response.
This is an unlikely set o coincidences, and the most
likely explanation is a bug, rather than no DHCP.
RD:
usually sw bug or misconfiguration of network.
Unknown (?): Do you have sufficient reason to convince that you really
need DHCP for v6. In this room, many people are against
this idea.
RD: I think that's out-of-scope
TN: DHCPv6 exists, we have a spec, and something which
describes how
to use it correctly would be good.
BA: I'd like to echo that. If we're using DHCPv6. This
is about describing how to use it correctly.
TN: We need to Focus on the Big Picture, and find out what
is causing the delays in configuration. Currently this
is being done in all different WGs, and we need to fix this.
RD: We need to clearly identify which problems are to
do with mis-administration.
GD: Talking about agenda (a little late for that). After
technical hitches, slides are available. Is there any
other existing work which we should cover?
<nothing from floor>
L2 Triggers Presentation By Alper Yegin (AY):
Detection and Reaction cycle:
Collect Clues: linklayer hints, network layer hints.
Make Determination.
Change Configuration: use some of the network layer hints,learn others.
Network layer can:
detect presence of new router (or absence of existing rtr),
detect presence or absence of dhcp server.
detect presence or absence of on-link prefix by
promiscuous snooping.
TN: What do you mean detecting on-link prefixes
by promiscuous snooping? What if the networks
are transit networks, with lots of different
networks' traffic on them?
AY: We're basically looking at theedge of the network
TN: I think that's a really weak assumption.
SD: We're starting to see networks hanging off what
used to be hosts.
TJ: We're seeing this in NEMO.
<missed>
AY: <presentation continues>
The link-layer could:
* tell ip when link is torn down
* tell when link is established
* tell the link id (i.e. ssid)
* other fancy features
Hosts may passively collect hints
* new prefixes advertised
* prefix goes stale
* prefix part of IP addresses change
* link up received
actively collect hints
* send rtr advertisement[do you mean solicitation?],
* learn the current link id
Who receives L2 Hints?
Preferably the host, but network side (e.g. Router)
hints may be useful too.
Interpreting detection of a new link
Doesn't necessarily means configuration change for network layer
There are some security concerns
BA: I think this is called a hint because may be
garbage. They're not authoritative.
If it's wrong, will I still end up with the right result
and just lose time?
AY: Collecting numerous hints leads to a decision.
We need to evaluate each hint and weight them
accordingly.
RA:
With security, you should not end up damaging
environment, or you could have damage amplification system.
What can we do at ietf? - define useful or practical link-layer hints.
The details are link-layer specific, so we must use an abstration.
One example of this is defined in:
www.yegin.org/alper/draft-manyfolks-l2-mobilereq-02.txt
We can communicate with other SDOs: IEEE handoff Exec Comittee Study
Group(ECSG). one of their reqs is to get requirements from IETF wgs.
Finally, we can define two movement detection schemes:
* when l2 hints available,
* when l2 hints are not available(partial mobility?)
BA:
In the case of ECSG, traffic goes other way. They're
looking for needs from us. i.e. should SSID change
be detected as default? Should they advertise
information elements with prefixes?
So they're looking for requests from us, so we need to
ask them.
SD: Been talk in TrigTran about complexity of solutions
we have (increasing). In trigtran they had advisory
notifications. Now you have a state machine to figure
out the hints. We've even been trying to decide if
hints are lying to us. This adds complexity, which
we mustn't lose track of. We need to be careful to
not go too far down this track.
AY:
We need a scheme that doesn't need hints to work, but
also need a scheme that can make use of those hints
that are available.
RD:
I agree l2 is useful and can provide hints. We may have
a different point of view on l2 hint details.
We need to at least capture pointers to l2 details
so we can know where to go to find these things.
TJ:
I'm thinking about Link movement without layer two hints.
May be cases where it can't be done
Are you just surveying things to provide guidelines
or proposing changes to layer three technologies?
GD: Mostly guidelines
TN:
Certainly want to at least survey the landscape. We might
notice that there are simple changes to protocols that
might aid us, and either do them here or hand off to
other groups. i.e. DHCPv4 needs update, or may be able to
define another v6 RA option to help.
JC:
For basic movement detection, link up/down triggers are
sufficient. For more optimized solutions we need other
triggers.
SD: Much better to have a scheme that tells the answer
rather than just giving hints
GD: Is this stuff in scope?
BA
This is relevant on collecting information about
links. Having a complex model or having lots of
state isn't helpful, because it's just a hint.
If you can get to the wrong answer based on hint,
there is a problem.
Erik Nordmark (EN): I get the feeling there are short term operational
issues for IPv4, and a desire to do things robustly
as well as performing better for v6. Creating
suggestions for getting better solutions at l2 is a
rathole that might detract from first two.
Writing down what's there or not is useful because
people can then understand what's going on.
TN:
A starting point would be a document that tells what
hints are available for various L2s and what
they are useful for. Maybe if we talk to IEEE we might
do something that makes more sense than if we don't
talk to each other.
GD: Is it worthwhile to catalogue L2 hints as a starting
point and leave recommendations for another document?
TN:
Do you have a potential charter, list of potential work items,
then people can say whether they think it's a right
direction, etc.
GD: There has been some talk that link-up triggers only is
a good place to start.
AY: <missed>
TN: It would be useful to enumerate the hints that are
available
GD: Are we just focussing on those relevant to movement
detection?
John Schnizlein (JS): It would be a wonderful world if we had a reliable
decision of link-up/link-down -
We don't have a simple state machine any more because we
don't have clear state transitions. In wireless we don't
know. We should stop calling these hints triggers.
They are really just hints. We should not make state
transitions on the basis of hints. A clarification, BCP
document might be very useful for implementors.
SD:
Maybe we need to focusing more on how things get put to use
differently as you get higher in the stack. I didn't realize
how many people expect to have applications react to these
things. We were thinking only of one interface in
Trigtranm but many people were thinking of more complex
environments, i.e. low/high speed interfaces.
I don't want to side-track this work, but there needs
to be work done on interactions further up in the protocol
stack, which is separate set of topics than what you are
talking about.
BA:
I'd just like to reiterate that even things that are
referred to as triggers may just be hints. Even link up.
look at definition of link up - it's unclear. 802.11f and
802.11i get triggered by different things for link up.
So if you believe that packets are lost, you might end up
disconnecting when you shouldn't, etc.
Unknown (?): 802.11 beacons are more than just hints; they are
real information of what has happened at Layer 2.
We have more than hints, we can start defining triggers.
AY:
This group should look hard into this, because benefits of
l2 hints are very clear. If we shy away from looking
at L2, we'll come up with a heuristic and when people
productize it, they don't know where to stick l2 things in,
and they'll break what we do in l3.
GD:
We've got an indication it's important to look at these,
and we'll discuss it on the list.
DAD optimizations Presentation by Youn-Hee Han (YH):
Proposal is to give background and current work about DAD
optimization.
Today, DAD is performed on all addresses, independent of
whether they're obtained by DHCP or stateless address autconfig.
Is this reasonable for all kinds of addressing domain?
Why optimize DAD?
L3 handover delay in MIPv6 using rfc2462 DAD between sending NS
and sending BU is 1s.
We want to make DAD optimization an issue in this forum.
existing works in this area, for stateless (optimistic dad),
and stateful (advance dad)
going over draft-moore-ipv6-optimistic-dad-02
going over draft-han-mobileip-adad-00
Next Steps?
As MIPv6 matures, the need for reliable and fast address allocation
and DAD schemes becomes critical to the goal of providing real-time
data services.
I: This issue has been done to death in IPv6 WG. We don't
need to do it again here.
GD:
It's been discussed to death with no solution,
but 1000ms is too long if you have existing sessions.
TN:
IPv6 views DAD as being necessary against disaster.
It's hard to debug and track down in the field. OTOH,
for MIPv6 this 1s delay seems to be extremely high.
What i personally would like to see is for somebody
to go through and do an analysis which explains what
all the delays are when you arrive at a network until
you can exchange packets, so we can do a systematic
analysis.
GD:
Maybe a draft like this should be submitted to MIP6?
TN:
When people say they need this, it would be nice to
know what real-time means.
Keichi Shima (KS): We're implementing MIP stack in KAME. In our
implementation, the biggest blocks of time are not DAD,
but detecting if the link is up or not. It is more
important to determine if the current CoA is still valid.
Modified MIPv6 proposals have effects outside of core
group. For example, the proposal to relax the router
advertisements interval. So we relaxed to 30ms. Almost
half of our CPU time is taken by router advertisements.
GD:
This is a motivator, we need to find ones which don't
consume Network bandwidth and CPU load.
Pekka Nikandar (PK): DAD is needed in some way. There's a big difference
between using random identifiers and those that are not.
For random addresses, waiting at all is too long.
With random addresses, probability is low and we should
use an optimistic scheme.
SEND decided to use CGA which are (almost) guaranteed to
be random addresses.
BA:
It's nice if a working group has a very well defined set
of things so it has a chance of succeeding. Then if you do
those simple things right, maybe you can feel good about
yourself and take on a different problem.
EN:
I'm on the fence with this one, because I agree with
Bernard, but lots of people want to make DAD faster.
So we need to make sure DNA is robust for v4 and v6 and
people want to do work for v6 and make it faster, and
DAD is one part of that.
Yes, we should pick a small piece and start with that,
but running in parallel independently is a bad idea,
because it may be a difficulty to get a fast and robust
protocol.
JC:
Do we feel dad optimization is useful, and is this BoF a
good place to do it? 1st question is yes, and if 2nd is no,
we should find somewhere else to do it.
Francis Dupont (FD): The decision for DAD optimization should be in
the hands of network managers, since he is the one that
has to clean up the mess in the unlikely event of
a collision.
tsatsuko from hp (T): I support this issue because DAD issue in this WG
is targetted for mobility enhancement. I'm interested in
DHCPv6 with optimization. Currently we have stateless
and stateful DAD approach. It would be good to have a
framework document to describe this.
GD:
Hopefully this is not a movement detection group.
This should be useful for hosts that are not doing
movement detection, but get detached and attached.
I think there are 2 issues: correctness and swiftness.
If we can handle both in one group neatly,
I would personally like to, otherwise I would like them
split off.
Question from Chair:
Who thinks DAD optimization is interesting for the IETF in some
form to look at and worth looking at?
(pretty much unanimous yes)
Who thinks this is a good match for the DNA working group?
(about 50/50)
TN:
I don't think this is a good match. This problem is pretty
self contained:
The cost of DAD is too high, and how do you get around it?
DAD comes in after you've already attached to the network,
so i don't think it's a good match for this WG. But DAD
work has been homeless for a while.
PN:
Reason why I'm saying no is because this is all part of a
much larger problem, which is being able to attach fast.
Saying DAD is afterwards, you make it serial, but these
are things that can be done in parallel, at least in
some cases.
TN:
I think there's a fear in the group that if we don't do it
now, we delay for another 4 months until we start it.
GD:
This BoF could also lead to more than one working group.
Gabriel Montenegro (GM): I want to point out this is the 2nd round; we
started in MobileIP wg. As we were rechartering, we were
told by the AD that maybe this part should be left out of
MobileIP groups. So if we're now told this is not the place
this should end up, we've already lost at least one round.
We should find a home for it immediately.
A v6 group that concentrates on correctness and swiftness
would be good. Even servers could be on wireless links
because people don't want to lay cables.
GD:
Is there an interest for putting v4 DNA alongside v6?
TN:
A lot of ll hints, etc is generic to v4 and v6. But what
you do about it (i.e. router advertisements), is different,
so split might be useful. I'm not sure which would be better.
doing them together brings more v4 experience and v6 goes off
more into theory land.
EN:
There is commonality, but protocols that you use to do this
might be different, so they might be different documents in
the same group.
PN:
I feel majority of wireless links in future are going to run
v4 and v6 at the same time. So it makes sense to work on
both in the same place. The main argument
against it is that some may not be interested in
v4.
GM:
Thinking about what bernard said, only 2 times he used link
local, all others were mistake. So maybe when you do
preferences, maybe you leave link local at the very end ..
assume it's in v6 or then v4..??
Many of these stacks will be dual stacks, so they have to
decide between v4 and v6, not just whether link is up.
GD: Haven't thought about that. I don't think that
would be a very good match if v6 detection was used
to configure v4.
RD:
Can you clarify direction of information flow? Are you
expecting for DNA info to go into DHCP, or get info out of?
GD:
We'd like to document what is available and how it
can be used.
RD: Information flow is in both directions: Collect
information on what is going on in DHCP, and provide
information from DNA into DHCP.
BA:
No opinion on where it should be done, but opinion on for it
to be completed. When you touch IP, you need a lot of eyes.
It takes a lot of skills, and you need a good review plan
and put together a set of scenarios that need to work.
Expert reviewers need to make sure it really does work.
So people in other groups need to be included in review
process.
Questions from chair:
What sort of deliverables might be possible to get out.
Should we handle version 4 and version 6 together in 1 wg?
(about 25 yes, 11 no)
TN: Is Network Attachment worth doing in a working group?
(most of room yes, about 4 or 5 no)
TN:
Who wants to have IPv6 DAD opt within this group?
(25 yes, about 6 no)
Going to try and form WG which handles these things.
TN: Need to go to the mailing list to define a charter.
Looking at the charter now isn't going to tell us much
more than we already know.
GD: Group will take on v4 and v6 and DAD optimization.
EoM.