[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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, ...