IETF-61 DNA WG minutes
Detecting IPv6 Network Attachment (DNA) Working Group
These are the minutes for the Detecting IPv6 Network Attachement
(DNA) working group meeting, held at the 61st IETF meeting on Monday,
November 8, 2004, at Hilton Washington. Thanks to Michael Richardson
and James Kempf, for the notes, on which these minutes are based
on.
Presentations and Discussion
Agenda and Document status
The DNA goals draft had been submitted to the IESG for
consideration to be published as an Informational RFC. The chairs
expressed their thanks to the editor, JinHeyock Choi, for his hard
work. For the other documents, see the explicit presentations
below
Link Layer Events and Notifications for DNA
Eric Nejdjou gave a presentation about the DNA link indications
draft. Currently the draft covers only a few different link
technologies, and it was decided already in the previous meeting to
add coverage for new technologies.
One particular confusing area appears to be in connection to using
PPP and GPRS. In particular, for the final end-host (like a laptop)
the actual IP link appears as a PPP link, not as a GPRS link. Hence,
in that scenario the "link up" event is generated when NCP concludes.
The situation is somehwat different when ther eis no PPP link,
e.g. when a 3GPP handset is directly communicating using IP. There
are also differences in address assignment in PPP, and this seems to
be confusing people.
- Bernard Aboba:
- Are you proposing a new IP address
assignment mechanisms, delivering the IPv6 address directly from the
PDP context, i.e., without router adverticements.
- Hesham Soliman:
- No. When PPP is not used, the RA/RS
gives you the address, but PPP gives it when it is used.
- Greg Daley:
- In the IPv6 case, PPP does not deliver the
address. It just hands over a unique interface identifier token,
which can be used to construct a link local IP address.
- Bernard Aboba:
- From the application point of view, that
is not a link up event. You don't have a globally routable IP
address.
- Pekka Nikander:
- The link is up for IP, not for apps.
These are two different events.
- Bernard Aboba:
- The draft does not make this clear.
There is lack of clarity on how IPv6 address assignment works in
this case.
- Erik Nordmark:
- The situation is similar when running
IPv6 over ethernet. There is a difference between the event when
the link is up for IP and when it is ready for apps.
(Some more discussion about IPv6 address assignment; the editor
couldn't make sense about the notes.)
- Rajeev Koodli:
- Look at som 3GPP2 proposals, they have
something on this.
- Hesham Soliman:
- If you can't get an IP address directly
from PPP, then this is a large problem, not just 3GPP.
- Pete McCann:
- 3GPP2 still runs RS/RA, they use PPCP to
get the interface identifier only.
- Pekka Nikander (chairing):
- There seems to be some
serious problems in the draft, maybe already in the introduction.
It looks like that we need more people working on the draft to get
this right.
- Eric Nejdjou:
- Applications never need to interpret link
events.
- Greg Daley (chairing):
- Let's take this to the list.
- Greg Daley (chairing):
- Should we add a section on 802.16
link hints? Are there any commercial interest on this?
- James Kempf
- No, we shouldn't touch 802.16 yet. The
802.16 mobility features are not mature enough yet. We shoudld wait
until it has been cleaned up.
- Ralph Droms:
- Let's wait until IEEE gets the document in
order.
- Greg Daley (chairing):
- How about 802.3 then? We
definitely should have a section on that. Any volunteers?
Editor's note: No volunteers during the face-to-face meeting, but
one was found afterwards.
Best Current Practice (BCP) drafts
Sathya Narayanan gave a presentation about a draft proposed as a
baseline for the WG BCP draft.
- JinHyeock Choi:
- Why so much emphasis on bi-directional
reachability? Partial connectivity is enough.
- Speaker:
- If you can easily check bi-directional
reachability, why not? I agree that partial reachability works, but
it is much harder to check for it. You need to check the
reachability of the current default router anyway; that is part of
what you just have to do. Hence, why just not do it?
- Erik Nordmark:
- Do you check the reachability of all last
hop routers, e.g., the all 17 of them?
- Speaker:
- Do you mean that we need partial reachability
with all of them in order to perform DNA?
- Erik Nordmark:
- According to RFC 2461, some connections
may go out over some routers, other on others.
- Greg Daley:
- "Before proceeding" set NC state to
"stale". May take 8 seconds.
- Eric Njedjou (?)
- After you have decided or when probably
moved?
- Greg Daley:
- It might still be the same link. If you
have an AP that says you've received an RA, that doesn't guarantee
that you can send something up through the router, may be
discontinuous.
- Eric Njedjou (?)
- The issue is to detect if you are
moving at all? To detect if you are on a new network or the same.
Or is it that wireless behaves differently?
- Greg Daley:
- Different link layers may have different
failure characteristics.
- Jinheyock Choi:
- Sure it would be nice to perform
bi-directional reachability checks, but not right as a part of the
DNA.
- Hesham Soliman:
- Are we trying to detect if we are on a
new link or if the IP configuration is still okay?
- Greg Daley:
- Yes (laughter).
- Hesham Soliman:
- These are two different types of
actions. The question is when to send an RS.
- Greg Daley:
- That will be covered in additional
recommendations.
- Jinheyock Choi:
- Is DNA by check for link change or by IP
config change?
- Speaker:
- It is not a clear either-or. It could be based
on explicit link od, or address validation, or default router.
- Vijay Depravalli:
- The default router's adverticements
may not include all the prefixes.
- Greg Daley:
- We need to define what is the best practice
for router configuration. For example, if it helps to have
overlapping prefixes advertised by different routers on the link, we
should define it.
- Speaker:
- Define the Best Current Practice, within the
current standards. Follow these procedures and things will get
better. For example, what is the preferred timer ranges. How
about recommending a subset of the existing range.
- Hesham Soliman
- There is no real current practice here.
Buf if we recommend something, it depends on the context in which
say that. For example, if we want to have short beacons, the
prefixes should be sent once. Hence, the recommendations will
necessarily have some context dependencies.
- Pekka Nikander (chairing)
- We should remember that one of
the primary reasons for the DNA WG to exist is that it is hard to
detect link change and update the configuration within the current
standards. Remember that we have also the solutions work, which is
separate from this BCP work.
- Greg Daley:
- The intention is that the hosts are able to
work in any access network, regardless of whether or not the
networks have the tweaks.
- Pekka Nikander:
- If we suggest something for the routers,
we have to remember that many people won't do it, i.e., they will
not tweak the parameters to get better performance. Rather we might
want to focus more on the host side; how to get reasonable results
there.
- James Kempf:
- We should also include advice for network
designers, how to lay out their networks, too.
- Pekka Nikander:
- Right, mostly host but also
network.
- Christian Huitema:
- We should tell the network managers
about the consequences, i.e., identify the tredoffs in
configuration. That is, you can do various things, but if you do,
you may gain flexibility but make roaming more difficult.
- Erik Nordmark:
- This sounds like two BCPs. One for host
implementors, telling them how to make the hosts to behave better
however the routers are configured. The other one on how one would
configure a router, network, etc.
(Sens of the room on two drafts, majority favouring)
- Rajeev Koodli:
- Do you need two separate documents?
- Vijay Depravalli:
- Are we describing what is out there,
or recommending a solution?
- Greg Daley:
- An example is CPL, which is a good idea in
certain situations. We want to illustrate tradeoffs and certain
configurations within the boundaries of the existing protocols.
- Vijay Depravalli:
- If recommending configuration,
couldn't that involve both the mobile node and the router. Hence,
shouldn't we just have one document?
- Erik Nordmark:
- If the document is split, then one half
will not delay the other, since the review communities are very
different.
- Hesham Soliman:
- There is likely to be dependencies
between host recommendations and route recommendations.
- Pekak Nikander:
- The CPL work should go into the host
document.
- Jinheyock Choi:
- The discussion about CPL is more
fruitful after the CPL presentation. The slide is misleading.
- Pekka Nikander:
- I think we need a separate document
focusing on hosts, maybe build around the CPL work.
Erik Nordmark gave a brief presentation about the current status of
the CPL work.
Solutions framework
JinHeyock Choi gave a presentation about the solutions framework
document.
- Greg Daley:
- Should we make this a working group
document? We might merge this with the eventual solution.
- Pekka Nikander:
- Should we adopt this, run a quick last
call, and submit to the IESG for informational?
- Vijay Depravalli:
- What if the outlined solution does
not work; shouldn't we have a link identifier draft first?
- Pekka Nikander:
- If it turns out that the outlined
solution does not work, we can change the RFC status to
historical.
- Vijay Depravalli:
- Shouldn't this rather be a document
that you take through with an implementation?
- Greg Daley:
- We have various options.
- Erik Nordmark:
- There is some issue with interactions
with the IPv6 WG, optimistic DAD. Maybe we should send a message
to them that we expect them to do something.
- Greg Daley:
- The IPv6 WG is proceeding with Opti-DAD.
Our solutions are not that advanced. The tentative link layer
address is not yet baked.
- Sathya Narayanan:
- Should we accept this as a WG item or
not?
- Pekka Nikander (chairing):
- Two questions:
- Should we accept this as a WG item or not?
- Should we proceed quickly with this?
Consensus in the room to adopt the document as a WG item.
- Sathya Narayanan:
- Let's make a compromise, not submit
it immediately, but wait until the solutions work is halfway
done.
- Samita Chakrabarti:
- The document discusses several
solutions in a framework. Is the purpose is to describe a framework
for different solutions in different cases, or requirements?
- Pekka Nikander:
- We should think about this as a
framework for thought, something that we can use when thinking
about solutions. The aim is to standardise a single solution in
the end. There are possibilities in this document.
Individual solutions discussion
- Chairs:
- The plan is to set up a design team of people
tha thave worked on the solutions. The design team then should
come up with a single solution.
Greg Daley gave a brief presentation about Fast Router Discovery
with RA caching, basically nothing that the proposal crosses layers 2
and 3, and enters a grey area for the IETF. The access points are
modified. It does not modify packet formats.
- Hesham Soliman:
- This is applicable only if the access
point is separated from the access router, and there is no protocol
to inform the access router about entering hosts.
- Jinheyock Choi:
- Some link layers won't need this.
- Greg Daley:
- It is trivial to include this kind of
functionality if you have a single access router acting also as the
access point.
- Hesham Soliman:
- The RA is sent by the MAC layer here.
I see this applicable only to WLAN where the AP is separate from
the router.
- Erik Nordmark:
- The generalized technique applies
always, also when L2 and L3 are combined.
- Vijay Depravalli:
- We want to make sure that the AP
cahces the most recent RAs. The AP needs to check every packet to
see if its IPv6, if the destination address is multicast etc.
(Presentation continues)
- Chairs:
- We recommed continuing this work as
experimental, either within our outside of the working group.
- Rajeev Koodli:
- So, you cache new router RA on AP. What
about SEND, RA/RS, grey area, could attach to rogue AP, to what do
you point?
- Greg Daley:
- If SEND is used, you can't accept RA until
you have checked authorization. That would require addtional
exchange anyway.
- Rajeev Koodli:
- We have to consider the host and ARw
security.
- Hesham Soliman:
- No strong disagreement to move forward,
but limited applicability. There is the danger of replay attack, no
strong need. This needs a strong applicability statement.
- Sathya Narayanan:
- If you have multiple rotuers, how do
you make choice about which RA to send?
- Greg Daley:
- That is not clear.
- Jinheyock Choi:
- When a host makes a new connection, l2
knows, l3 doesn't. AP or base station initiates RA earliest possible
time. AP in 802.11 specific case.
- Rajeev Koodli:
- Many APs today are capable of
doing some IP stuff.
- Chairs:
- We propose experimental. Should we proceed
within the working group or as individual work. Anybody
interested.
Only one hand in addition to the authors.
- Chairs:
- Continue as individual draft, but solicit people
to do external review.
Greg Daley gave a brief presentation about Deterministic Fast
Router Advertisement Configuration.
Brett Petland gave a brief presentation about Router Advertisement
Link Identifiers.
- Pekka Nikander:
- Have hash of all prefixes of link?
- Speaker:
- Was considered, too complex, need to keep track
of all prefixes on link, need to detect and change link id.
- Greg Daley:
- Tradeoff between large unique number or
something that only has local unique properties.
- Speaker:
- Simpler to pick a large random number. More
overhead though.
- Erik Nordmark:
- First, a prefix option with no other flag
set has no semantics. The host only acts when one or more flag bits
are set. One possibility is to advertise a prefix for the purpose of
being a link id, with no other bits set. Second, we have to
consider how long it takes for a link id to experire and how long
does it take for one to travel. You travel around world w. laptop
suspended. How long is the travel time and how long is the expiry
time? The host will forget. Limit times when collisions occur. How
bad is it?
- Erik Nordmark:
- NC goes to stale. One of addresses may
have a preferred lifetime, move, get another prefix, think old
prefix is valid because lifetime hasn't expired.
- Tony Hain:
- Any concept using prefixes is wrong, prefix
will change, don't want link id to change when prefix changes. 48
bits, local prefix. Use 64 bits to pad. Global ids won't work.
Sathya Narayanan gave a presentation about Router Reachability
Detection.
- Greg Daley:
- Failings of DRA is that some hosts will pick
up same router, change which responds fastest, all routers know
which order to respond, router to respond first, others delay around
list. If router not part of list, DRA rules. If not in list, then
sent quickly.
- Erik Nordmark:
- Does this draft propose that all routers
agree what designated prefix is?
- Speaker:
- No.
- Erik Nordmark:
- Used router and prefix. Are they still
there?
- Speaker:
- Yes. Two different hosts have two different
ids.
(Some discussion missed.)
Sathya Narayanan gave a presentation comparing the approaches.
Summary
- The Link ID draft apparently needs more work.
- Aim for two BCPs, one for hosts, one for network configuration.
- Adopt the solutions framework as a WG draft. No consensus on
the pace of going foward, discuss this on the list. Does not
restrict the design team work.
- RA caching as individual experimental until more interest.
- Jinheyock Choi:
- The chairs did not ask author, chairs did
not mention presentation to him beforhand.
It appears that there were communication problems between the
author and the chairs, and therefore this decision was decided to
be made void and to be reconsidered on the mailing list.
- The chairs will form a design team that will consider the
various solutions drafts, with the goal of coming up with a
proposal of how to go foward at the next IETF meeting.
Consensus call on forming a DT; about 20 hands in favour, no one
objecting.
|