DNA working group meeting
Chairs:Greg Daley, Suresh Krishnan
Minutes: James Kempf, Mohon Parasarathy
Discussion of agenda
Additon of some items
- call for reviewers
- tentative option
Link call draft sent to IESG , LC approved
CPL sent outside for review, not much changes, just clarfications.
Ready to go. Make consensus call on the list to check for more
FRD document as WG document in the last meeting.
Please take a look at the IPR, filed in Korea.
discussion of drafts
- WG last call on Alper's draft complete, to IESG
- CPL draft to last call
Last meeting, FRD is WG doc, review needed.
DNA hosts draft updated:
Presentation by Sathya
We made the DNA steps explicit..
there are 3 steps.
- To see if you have cached information and make use of it. If there is no information,
- make all the addresses as optimistics
- Conduct link identification
Prior info stored related to the links the host visited in the past
- link change or no useful prior info, follow procedure below
-Change IP config
- configure DAD
Non link change
-Restore address config state of all addresses
- Conduct reachability detection to one of default router
We don't say anything for MLD join for solicited multicast address when setting
proposed text from ErikN's email:
- Host must send MLD join for the solicited node multicast group before
sending RS message for the CPL
- Not before RS, but MUST before DAD NS (It MUST be done before RS or NS.)
- Do it before sending RS. .
- After change state to optimistic
- Doesn't have to be that early. Can stay in optimistic forever, but ND is
inefficient, can't send NS, must send packets to router. Constraint is loose,
important that it gets sent and then send DAD probe, then wait for a second.
Might be later
- Tight constraints on this. Need to send before the RS. Presentation later,
has to do with snooping switches
- Diff (will send link to mailing list)
Router BCP Update
Brief update draft-ietf-dna-routers-01.txt
Did not make many changes
Removed section on Disjoint admin
about: - Routers should not advertise that belongs to different admin
Anything else needed here? (No comment)
Removed background w.o. recommendations
-Diff (will be posted to list)
Greg: Review needed on both docs, contact chairs if you want to review
Want to get docs advanced soon
DNA relocation delays
Presentation by Greg, doc written by Chris Vogt, et. al.
addresses MLD join issue in Sathya's presentation..
When we change POA, determine IP address change very fast. Involves
IPV6 RD, ND,
- MN configures new address, etc.
RS (TSLLAO) from MN to AR
RA back (content depends on router on access link)
after reception of RA, additional addr and routing config
IP reattachment, BU etc. may happen after that..
Optimistic Addresses need to go through optimistic DAD
Sending NS requires prior transmission of MLD Reprot
MLD Report should be randomly delayed up to 1 second during interface intialization
(RFC 2461/2462 bis)
Objective of delays to desync simultaneous bootup of multiple hosts
- but it prevents fast IP reattachment due to MLD Report delay
Power goes, power comes back up, all hosts will send at the same.
- Delay was there to introduce cthe concern.
- key word is interface initialization. Moving, not
- Not bringing interface up and down when moving
- When you are moving around, this delay may not be needed.
GReg: Still need to say something
Erik : Just say that DNA does not ....
Adding something to 2461bis would make sense ?
- saying don't do if MN
It has to be in 2462bis or MLD ?
- Would need in MLD also
- Don't think it needs to be in MLD...
delay is in MLD also
- 2462bis, matter of RA
- Current draft req. on amount of delay for MLD transmission when reiniting the interface
- discuss in IPv6 WG, Our (IPv6) consensus is that it is too late
to change in rfc 2462. random delay remains, will remain in RFC.
This delay is not needed (Personal). No clear consensus on IPv6 WG.
Greg: We have to make some decision.
- Trying to clarify
-This might be where to do it,
Goal of this draft is to make recommendations
- Is delay not needed?
- Clarification makes sense.
- No impediment from IPv6 WG, should we do it.
- Erik's point, discussion on RSes and soforth, global clarification that chaning
APs and interface init are not the same thing. Don't put same constraints
on moving between APs as on init
MLD report sent before oDAD NS, delay is not necessary
RS is tricky one
RS/RA - no additional messages between them.
Router understands the tentative options and hence sends RA. If the router does not
understand TSLLAO, things may not work.
If not, can't push LL addr, which would lead to NS/NA exchange which would need
Omit delay for initial MLD Report upon movement
there might already be desynch at the link layer when you attach from moving
Start optimistic DAD before initial NS, use for RS prior to NS for oDAD
Erik Nordmark comments
oDAD is set up so you don't have to complete before you send RS/RA. Questions about
wording in spec, oDAD spoec still says you must send NS when you go optimistic.
Can go into optimistic mode, send RS, then MLD Report. If RA says didn't move,
turn off optimistic mode
Cost of opti mode is low enpough that you can stay in as long as needed
If router supports DNA, you get response immediately
RS/RA, then do MLD
MLD snooping switch, multicast is not treated like broadcast, then switches
need to have multicast group state, need to send MLD group join at new port
before you can send NS. Legacy router, will try multicast delivery or unicast
delivery RA with NC entry. Snooping switch won't get NS.
MLD group join, won't get NS if router sends it (due to lack of NC entry),
because snooping switch doesn't have state
Greg: MLD required only for solicited node multicast..
Ignoring SNMCaddr, moved or didn't, hint is layer 2 move. Need to send MLD reports for all. Movement at L2 matters for snooping switches.
To get RA, only intereseted in NS, so only interested in SNMCaddr
But what about other multicast groups, don't know if switches are snooping, can't
tell if moved port
DNA router will support tentative options
If not, normal response would be multicast
Assuming multicast for legacy routers, don't have snooping switch networks
Router only send multicast if scheduled to send, normal behavior is to send unicast
SHOULD in 2641
Legacy router sees no don;t understand TSLLAO. either needs to resolve with NS or
multicast the RA back
Question, if you have legacy router, if it tries to unicast (sends NS),
then host sends RS. Host sends RS, doesn't see response because switch drops
multicast. Need to do the MLD at some point in time.
Eventually recover on multicast RA
Bigger problem with MLD in general, manditory part of spec, need link layer trigger
Hesham : eventually Router might send a RA.
MLD in general. MLD and snooping switch. If the interface goes up and
down, then need to do elaborate procedure of joining all groups..
How do you know interface went down and came up.
WG doc describes link indications (could look at DNA triggers)
Reduce delay for MLD, special case for interface already up, how do you
distinguish that it is a special case? Hard to special case.
We are already making a special case..
Already using special case for RS
Generic problem, synch is a problem, don't know how many MN are doing it
MLD problem might be solved here or somewhere else
2 questions on MLD join. Neither question are answered in host BCP. What should be done?
suggestions about general guidance for difference between reiniting and moving.
Is that something we should look at? Difference in delays should be identified.
Might not be explict DNA thing.
Sathya: should do in DNA?
Hesham : Years of confusion in interface goes up/down, should be done in DNA.
We can try to put into host BCP draft
Or possibly MLD draft
MLD join, done when L2 hint or? Quesions are open.
Suresh : Right place to address is DNA and not IPv6 because IPv6 is not worried
about getting the documents out so fast..
a reference is not very good. Should address in DNA.
Sounds as if a generic issue for MLD with snooping switches
Not fast enough for us, it is in MLDv2bis but it is not clear for movement.
Ref in 3590.
Router gets RS with temp SLLA, repsond with RA to that address or send multicast.
Can it do an NS?
Greg: Yes, the receipient can do an NA with override flag reset
What is requirement for node that hasn't sent MLD
distinction if multi or uni. some daemons don't know if there's a NC entry
NS, address is still optimistic.
Recpipiet can do NA w.o. setting NC enttry
Before RS, set to optimistic
Dosn't need to send NS right away, incorporate guidance deferral of
NS whether or not separate guidance for MLD, another story
(sense of room)
Distinct problem that generic guidance for difference between movement and
initialization, and document.
(hum) - nobody against
Separate document to describe guidance for differences between movement and
separate doc: (confusion on question)
Sathya : Host BCP document. Adding more drafts is not good.
Brett: Applies to both BCP and Solution dradft.
(Greg puts the question into a slide)
a) separate document
b) PUt in existing DNA docs.
Pat Stevens (HMS)
There might be scenarios where there might be an interface going up and down
Might not know if transmission event, might look like movement but
might be same behavior like up and down. All hosts lose connectivity,
looks like a mobility event, but same behavior as interface up and down
Looked at it for 11b, same for BS failure and everyone moving out of
range at same time, missing beacon, etc. Devices moved out of range
simultaneously. In 11b, serialization done at 802.11b probe phase
did some serialization: LL desyncs. Some link layers will sync, but
with certain MACs, will desync.
Also most MAC layers, handled by MAC. If you're already assoc with AP,
lose AP and comes back up, no contention based access. If you need to
go through contention based access, problem.
Point well taken. We will say clearly that "If the link layer is
desynchronised.." do the following..
Same document or Existing document ?
Back to concensus call
A) Separate document : No Hum.
B) Existing Document : Hum.
draft-vogt is not a WG document, so not "existing"
draft-vogt solves two problems
Question, what is DNS hosts BCP for? Can be regarded as protocol
change or variation, might not best if protocol change
hosts document is a BCP and not standards track.
We can make hosts doc standards track if necessary
More general concept. And not specific to vogt*. Need to describe
how you know diff between init and mobility, makes sense for generic doc
Greg: Do you think it is a DNA thing ?
Hesham: Yes, it is.
Suggestion. Don't get working group consensus yet ? Don't know
what is described in these documents.
Have people working on docs work this out.
Who thinks we have enough understanding to make a decision?
do: no hum
Group consensus is that there is not enough understanding about what is
contained in these documents.
Take it to the list.
Talk on the list about when MLD join should be done
FMIPv6 and DNA
FMIPv6 usage with DNA protocol
Presented this at Paris,
To document how FMIPv6 can be used with DNA ?
FMIPv6 makes use of neighborhood information to expedite handovers ?
FMIPv6 makes use of neighborhood info to expedite handovers - resolve AP
ids to router mac and IP addrs
DNA provides fast movment detection across subnets
Scenarios where neighborhood information is not avaialble, DNA
Nhood info might not be available, DNA can assist reacitve handover
(description of protocol)
can help fast reactive handover MN associated with Access point
and obtains the AP-ID, Ar-info, if information not available use DNA
Rtr solicitation with DNA extension
MN sends a FBU to PAR directly
PAR sends HI message, Handover acknoweldge message
PAR sends FBA
PAR starts tunneling packets to MN's new COA
Current spec, encap fast BU inside FNA, if oDAD used might cause collison,
but no fifference with normal oDAD
Suresh: Informational document. How many folks have read the draft ?
- couple of folks.
Accept as WG item ?
Suresh: Useful to document? (30 hands)
Not interested? (no hands)
Interest in doing work
There is interest in pursuing this work.
Hesham : RFC 4068 is being updated. Done there or here ?
4068 is being updated. Should it be done in 4086 or here?
Why do it here? No protocol modifications, just documenting steps.
DNA is right place to do it. Can reference, if you resort to DNA, here is how to do it.
Should this document in DNA WG? 12
Do elsewhere? 3 hands
Concensus to work on here
James Kempf : Splitting the work into multiple documents makes it hard..
No Hyper links. Searching too many bits..
Rajeev: Instead of cleaning separate protocols, have a single monster.
No normative dependency.
Greg: We don't have to push this if FMIPv6 comes out as proposed standard
Solution document presentation, draft-pentland-dna-protocol3-00.txt
Based on two piror proposals
(describes link idnentification, landmark prefix)
FAST RA and link-id
Fast RA: Calculate token based on RAs from other routers and RS and calculate token
- routers listen to all prefixes on the link
- new option for learned prefixes
- one of them is marked as link-ID prefix
- hosts include a landmark
- landmark yes or no
- unsolicited RAs may carry a subset of prefixes but must include a link-id
- RAs include a link-id prefix
- moving to new AP still includes the prefix,
Identification based on non-prefix information, no supporting emails on ml
Explicit link-identifiers - mark the prefix: alt non prefix (biggest issue)
TSLLAO option, where does it belong
Delivery of MLD packets during DNA (presentation to follow)
Where is the TSLLAO draft?
Not in any WG, individual w. IPv6 tag. Separate draft, may need to have it
separate if additional uses. Primary use DNA, include in base DNA spec.
Generally applicable w. oDAD, send unicast NS, send this option instead
of destructive source link layer document.
Suresh : How many have read the document ?
Suresh : People with issues last time, are the issues solved now?
Should we adopt this as WG document ? 23
NO : zero
Consensus to accept it as WG document.
Non-prefix link identifiers :
Could be useful in adhoc networks. Explicit link ids could be useful, could
be easier to include now.
OK to be an explict prefix id
Brett: Can RS/RA even work in adhoc network ?
JinHyeockChoi : DNA is good with explicit link identifier. Host can check for
link change for link identifier even for RA. Linkid
Not based on prefixes
Questions to resolve in adhoc
Link id, explict id is more friendly to ad hoc environment, host can check
with complete RA. Link id is landmark prefix, prefix all routers know,
link id prefix is natural choice. W. explicit link id more gracefully
deal with link prefixes changes.
Some crossover, need to figure whether we need first, non prefix, or whether
simpler to incorporate now.
Mesh networks, RS/RA, is this compatible with mesh
Nonprefix ids, still might need explict w.o. nonprefix (i.e. explict but prefix)
prefix like ids but not a prefix. Don't know what ad hoc is. If you need to assign
some form of id, does it have to be different than 128 bits? Can you use ULAs, but
not too many. Don't set L or A bit. As long as I can use as link id, just use with
DNA. Don't know what might be needed, keep door open. Only used for link id
purposes. Don't know requirements.
Explicit link id in router advert, rather than using prefix from prefix list?
ULAs are just prefixes, bit that says its a link id, but not a routing prefix
to say that don't use it for other purposes. But don't know enough about
Hosts don't know that there is a link id, do hosts need to understand what is
the link identifier.
Suresh: Pick a 128 identifier,looks like a prefix, mark as not a prefix,
someone will still use it.
We don't know enough about it to work on it, so I think we should postpone.
Another issue, how do we come up with this link id, manually configure, we are
not ready to work on this.
Agree these are issues, but Greg suggests scheme to solve two at once
Sathya: Two problems
Agree w. Suresh. One, devices agreeing on common id to define link,
having separation between routers and hosts, no definition from
ad hoc network point of view, open for ad hoc. We are just trying for small
forward compatibility, add a it somewhere. Will this make a difference?
(as nonchair) If we wanted to do nonprefix link id, we would need to track validity of id separately from prefixes, not something that we have not really done much on. Would it be OK to add nonprefix ids later as an option. Absence of nonprefix, use prefix ids only for DNA.
Are you saying that we should have an explicit link identifier?
If we don't know how to do this now, we can get away with not defining these now, add explicit link id, we could add it in later, won't hurt operation of this draft.
Then would redo DNA
No, just nonprefix link identification
Wouldn't overlap condition on hosts still apply? One router with idnentifer?
Agree with Sathya
Hesham : Use some bit for indicating the DNA operation.
New bit, needs to be present in all adverts
Just an entry in prefix list though not a prefix
Ad hoc, not clear what is valid link configuration. Wait until it becomes clearer.
Do we need to add even later? Can have prefix, enough flags to indicate to use for
autoconfig or not. Use for either case. Diff is can you use it for generating addresses.
How can you solve this problem? Smallest prefix is fine, just stick with that.
Change will not be that costly on existing. Lot more changes on router behavior,
agree on an id, etc. not suggesting this.
Not necessary to define a new id, whether to announce explicitly
Don't mandate if use prefix as link identifier, could be a link identifier.
Say that it is lowest prefix, but can change it.
Don't tightly couple. Decouple
Mohan and Suresh argue about how to do this
Current solution will break down, have to mandate something for the current problem.
Separate idea of prefix from link id? Routers have a way of selecting different link id.
Should be open to having not having shortest prefix, but we should have a default.
Routers put flag in saysing this is link id, default is shortest prefix, but possible to change in future
Flag for link id, what's the point of shortest?
Routers need to agree.
Host isn't involved. Routers need a way to pick this.
Say that explicit, separate bit
One step, this is link id. Two, can you use to configure addresses
Some of bits are in prefix info options.
One bit may not be sufficient
Normatively referenced by two documents, which are WG docs
IPv6 chairs want this done in DNA cause IPv6 WG is going into hibernation
Greg will present
(briefly summarizes draft)
Optimistic DAD does not let you use SLLAO:
RFC 2461 has a SLLAO is an option to provide the link-layer address
in order for the receiver to respond without doing NS.
Problem with SLLAO is that it always overrides NC entry in the receiver,
would like to get unicast back to an optimistic address
If we are not sure whether we have arrived on the new link, we need
TSLLAO so that we don't destroy the NCE.
TSLLAO does not destroy NC entry
Implementation in Linux available from Greg
RS can't be unicast without option, need to do NS. Necessary to have
this done, IANA allocation
Solution all you need is Mac address for repsonse for RA, create NC
entry for packet. Optimistic DAD is written such that create an NC
entry if you don't have it.
Can send unicast packet back without a Neighbour Cache entry.
Does create entry if no entry is there?
With oDAD, small chance of collision, if there's a collision, we want
operations to be safe for original address owner, advantage if temporary,
won't create or modify an entry (GD: if an entry exists). MAC binding will
be delivered to another destiantion if there is another NC entry.
Suresh: Is there an interest adopt this work ?
WG item - 8 hands
Consensus : Do it on mailing list ?
Know it's a late agenda item, not trying to shove something through.
Should this be in a separate document? 5 hands for
Part of solution document? 2
confirm on list
Vijay: Small extension, should be part of solution.
Brett : Keep it separate because FRD uses it
DNA solution protocol by April 2006:
- Interested in the document ?
- Looking for significant comment before that to make that decision ?
Revise milestones- need to come up with realistic dates
Need to set milestones that reflect dates by when documents delivered.
Can submit link layer hints to IESG (passed last call already) next week
- can we get it reviewed by Jan. next year?
Would include MLD relocation and other guidance
Willing to review docs? 3 hands
Vijay, Hesham, Bret, Mohan volunteetered to review..
draft expired, anyone interested? (no hands)
Anyone opposed to let it die? (no hands)
Bretts doc doesn't make clear why it was designed a certain way. Is other
document a design doc or a solution framework? Doc was available in Mobike.
Confirm on mailing list
Write framework after? No objection. Will talk to Maragaret.
Solution doc done
Interest in helping complete by April 2006? couple hands
Some people are interested.
Significant comment required before March