2.3.14 Detecting Network Attachment (dna) Bof

Current Meeting Report

Agenda
======

Chair: Greg Daley

Introduction/Agenda Bash (5 Min - Chair):

Problem Description/Existing work (40 Min):
- Movement Detection in Mobileip (JinHyeock Choi)
- Link Detection in zeroconf and DHCPv4 (Bernard Aboba
- Address confirmation in DHCPv6 (Ralph Droms)
- discussion

Issues (40 Min):
- Link Triggers (Alper Yegin)
- optimized DAD (YounHee Han)
- Discussion: Common ground - Mobileip, IPv6, zeroconf and DHCP
- Discussion: 'v6 only' or 'v6 and v4'

Interest and Focus (15 Min - Chair):
- Work Plan Proposal
- Interest in WG Formation

BoF Description (If you don't have one)
=======================================

Detecting Network Attachment (DNA) BoF Description:

Network Attachment occurs when a host arrives on a new IP subnet. When 
attaching to a network, a host either already has a valid 
configuration for this subnet or must configure addresses. A host 
determines whether it requires additional configuration by Detecting 
Network Attachment.

When a host has existing upper layer protocols sessions, it is 
important to receive a timely indication that attachment has occurred. This 
may be the case if a host is connected intermittently, is moving or has 
urgent data to transmit upon attachment to a link.

For these nodes, it is also important detect if an acquired link is new, or 
has already been visited. This information may be used to 
distinguish between events where configuration must be initiated, or a host 
already has valid configuration.

This meeting hopes to providing a forum for those interested in 
developing generic attachment detection technologies for IPv4 and IPv6.

The BOF aims to:

* Describe existing issues encountered in DHC, ZEROCONF and Mobileip WGs, 
which could benefit from work on detecting network attachment.

* Define the problem scope, and environments where network attachment 
detection is desirable.

* Determine if sufficient interest exists to form a Working Group on this 
topic.

* Reach consensus on the area of work for a potential WG, including which 
problems are outside scope.


Meeting Summary:
================
Summary of the DNA BoF Meeting
at IETF57, Vienna, Austria
Friday, July 18, 09:00

* Text (Contributed by TJ Kniveton and Brett Pentland) of the meeting 
discussion is available online at: 
http://www.ctie.monash.edu.au/dna/minutes57dna.txt

Decisions
---------
1. DNA Worth doing as a working group. (most hands for, 4-5 no)

2. V4 and v6 should be together in the working group. (for 25, against 10)

3. DAD optimization within the working group. (for 25, against 6)

Action Points
-------------

AP1. Develop a WG charter for Detecting Network Attachment.
   AP owner <GD>
   Target Date: BoF LC to be completed by late August.

AP5. Discuss whether cataloguing L2 Hints is useful
   (consensus call?)
   AP owner:  <TBA, initially GD>
   Target date:  mid August

AP2. Link Localv4/DHCPv4 interaction clarification
   AP owner:  <GD, Zerconf, DHC WG Chairs>
   Target date:  to completed before mid August

AP3. Link Localv4/DHCPv4 issues and guidelines document
   (informational?)
   AP owner:  <TBA, not discussed> (suggested by TN/BA)
   Target date:  to completed before mid August

AP4. Mobile IPv6 Handover Delays Description Document
   AP owner:  <TBA, initially GD> (suggested by TN)
   Target date:  mid-late August

AP6. Establish Liaison with IEEE ECSG
   (? Not agreed, depends on L2 Hints in WG)
   AP owner:  <TBA, intially GD>
   Target date:  end of September


Meeting 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 Trigtran 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.

Slides

Detecting Network Attachment (DNA) BoF
Movement Detection in Mobile IPv6
Detection of Network Attachment (DNA) in IPv4
DHCPv6 Address Confirmation
Link-layer Hints for Movement Detection
DAD Optimization