Re: dna bof report

["James Kempf" <kempf@docomolabs-usa.com>]

Itojun,

I wasn't at the BOF, but your note outlines my concerns about it. We have
not had much success with WGs that have charters that are so broad
(examples: Seamoby and Zeroconf) and while there are certainly individual
factors in each case that led to lack of success, I think it might be wise
to focus some. In particular w.r.t. IPv6, focus on work needed in ND for
this especially w.r.t. what we have learned about wireless in the last 5 or
so years since 2461 was completed might me technically more productive,
though there may be management reasons why that course is more difficult.

            jak

----- Original Message ----- 
From: "Jun-ichiro itojun Hagino" <itojun@iijlab.net>
To: <iab@ietf.org>; <iesg@ietf.org>
Cc: <itojun@iijlab.net>
Sent: Friday, July 18, 2003 11:26 AM
Subject: dna bof report


> overall:
> lots of talks on tips and tricks to detect network attachment, avoid IPv6
> DAD delay, mobile-ip6 stuff, and such.
> the solution space spans too broadly, and conflict with
> other WG too much (ipv6, dhc, mobileip, L2/L2.5 maybe).
>
> is the goal (1) propose fix to other wg's document and
> (2) do some Informational/BCP?  or something else?
> i see that they have problem to solve, but i'm not sure if it can become a
WG
> by itself.  they should visit other WGs and raise issues instead.
> (could AD who hosted this BOF give some suggestion/clarification?)
>
>
> www.ctie.monash.edu.au/dna/
>
> - mechanism to determine whether it is attached to a network
> - intermittent connectivity, mobility/nomadic
> - existing upper layer time constraints
>
> - find one or more way to reliably detect that we're attached to the
network
> - inform upper-layers
> mobile-ip[46], dhcp, tcp/udp,
>
> mobile-ip6 moving detection
> dhcp6 confirmation messages
>
> Problem Description/Existing work (40 Min):
>
>
> 1 Movement Detection in Mobileip (JinHyeock Choi)
>
> MD overview, proces, methods, problem,s, requirements
>
> hint
> checking the reahability of current access router
> checking the validity of the current care-of addr
> router discovery with all the necessary info
>
> inconsistency of RA info
> delay to check the reachability of current CoA
> random delay in rs/ra exchange
> erroneous detection/unnecessary signallng
>
> requirement/further steps
> MD scheme requirement
> fast/low time delay
> precise/secure/little error
> efficient/limit signalling
>
> TJ: which upper-layer needs to be notified?
>
> TJ: problem domain:
> solution for everyone
> fast handover (going experimental - not for everyone)
>
> choi: asked implementers, there's no clear single way to do this
>
> TJ: lower-layer.  huge difference depending on which lower layer you
> are on.  problem domain?
>
> basically looking at L3 technology, but L2 hints would be nice
>
> choi: solution should not depend on particular L2 technology
>
> 2 Link Detection in zeroconf and DHCPv4 (Bernard Aboba)
>
> why the interest in DNA (detecting network attachment)?
> todays' hosts are often mobile
> ip config latency is a significant fraction of
> total roaming latency
> assignment of an ipv4 linklocal address typically
> the result of the bug in the host/network fault,
> nor detectionor of adhoc network
>
> DNAv4 model
> hints - non-definitive info L2 hints , L3(IRDP)
> most likely point of attachment (POA)
> reachaability detection
> address re-acquisition
>
> what RFC2131 says
> what zeroconf-ipv4-linklocal says
> a bad idea if taken literally
> implications
> host connects to an adhoc POA, selects ipv4ll addr
> host moves to another POA
> performs ipv4ll claim and defeend
> uses selected ipv4ll addr
> host never obtains a routabele address!
> solution
> don't select an ipv4ll as a first resort OR
> test reachability of autoconf neighbor(s) first
>
> DNA is an important aspect of mobility
> poor implementation can result in mobile hosts that are never connected
> some grey areas in rfc2131, ipv4ll spec
> quesetion; where should this work be handled
>
> droms: how to proceed?  1 doc, 2 docs, 4 docs?  multiple working groups...
> spencer: in trigtran there was some discussion
> narten: spliting document may be good
> sra: need to fix zeroconf
> droms: need to fix dhcp as a response to fix to zeroconf
> itojun: how to publish?  informational? - yes
>
> droms
>
> retransmissions and timeouts
> exponential backoff with initial randomization
> issues w/ dhcpv6 address confirmation
> need to know dhcpv6 server availability (prior RA)
> need for configuration of link-instance prefix knowledge in routers or
dhcp servere (for notonlink)
> failure on non-response may occur if no dhcp server on new link
>
> bernard: timeout happens only when you're using dhcpv6.
>
> Issues (40 Min):
>
> 1  Link Triggers - presentation (Alper Yegin) and discussion
>
> detection and reaction cycle
> collect clues
> make determination
> change configuration
>
> detect presense of a new router
> detect presense/absense of a dhcp server
> detect presense/absense of an on-link prefix
>
> narten: the last bullet seems weak
>
> notees
> twho receives the L2 hints
> interpreting detection of a new link
> security concerns
>
> aboba: hints = "could be garbage"
>
> what can we do at ietf?
> define useful practical link-layer hints
> details are link-layer specific, so use abstraction
> IEEE handoff ECSG
> define two movement detection mechanism
> when L2 hints available
> when L2 hints are NOT available
>
> they are hints!  we shouldn't rely on hints 100% (bad
> mistakes from hints).  we may make a catalog of hints (BCP).
>
> 802.11b beacon could be more than a hint
>
>
> 2  optimized DAD - presentation (YounHee Han) and discussion
>
> DAD is performed for every address
>
> is it possible to perform seamless L3 handover
>
> DAD NS, wait 1 second, then BU
>
> optimistic DAD
> advance DAD
>
> next steps
>
> itojun: done topic in ipv6, no need to repeat here
> narten: don't focus on DAD only, maybe mip6 wg?
> keiichi: DAD is not the biggest delay source.  modifying L3 layer will
> affect other standards/implementations.
> pekka: DAD is needed in some way.  guaranteed randomness of address
> then it'll be good.  SEND uses cryptographic address
> aboba: outside of scope of this BOF.  start with small problem.
> nordmark: outside of scope of this BOF.  start with small problem.
> robustness/speed tradeoff
> choi: (1) is optimization useful? (2) is this BOF suitable?
> francis: decision should be up to network manager.
> ?: mobility issue, so different from ipv6.  need comparison document.
> chair's personal: correctness and speed
>
>
> 3  Common ground between Mobileip, IPv6, zeroconf and DHCP - discussion
> 4  'v6 only' or 'v6 and v4' - discussion
>
> narten: L2 behavior is common to v4/v6, L3 might be different
> do both.
>
> v4/v6 together 35
> v4/v6 separate 11
>
> wg or not?
>
> narten: charter? - yes there is
> ....
> aboba: need a good review plan, if you miss something it would damage
others
>
> some straw-polls
> v4/v6 both
> want wg
> do DAD issues
>
> need to go to the list, refine charter, ...
>
>